בטבלה 'items' לכל רשומה יש את השדות: id,value
הבעיה היא שאני צריך להוציא את השדות בצורה ממויינת (לא לפי סדר לוגי, אלא לפי סדר שהמשתמש קובע). הדרך הפשוטה ביותר היא להוסיף שדה place שיחזיק את המיקום של המיקום של הפריט ברשימה, אבל הבעיה היא שאם אני ארצה לשנות מקום של פריט ברשימה אני אצטרך לעבור על כל הפריטים שאחריו בסדר ולעדכן את השדה place שלהם, וזה פשוט לא פרקטי עקב מספר השורות בטבלה.
המצב כמובן מזכיר (לי לפחות) מקרה של רשימה מקושרת, כלומר להוסיף שדה next_id שיחזיק את הid של השורה הבאה ברשימה, אבל אני לא יודע אם כך איך להוציא את הנתונים בצורה ממויינת.

יש למישהו הצעות איך לפתור את הבעיה? חשוב מאוד שאני לא אצטרך לשנות יותר ממספר קבוע של רשומות עבור הוצאה/הכנסה/מחיקה/שינוי מקום של איבר ושאני אוכל להוציא את הנתונים בצורה ממויינת, עדיף מאוד בשאילתא אחת.

אין ממש חשיבות למסד הנתונים, אבל בשביל הפרוטוקול נגיד שזה mysql

אתה יכול לפעול עם ה-next_id כשיש לך אצל המשתמש מידע עם ה-id האחרון שהוכנס (נקרא לו last_id)

ואז תעשה שאילתה:

קוד:

SELECT * FROM tbl WHERE next_id BETWEEN 0 AND (SELECT last_id FROM users_table WHERE user_id=4)

בחלק של user_id=4, אתה צריך לשים את המספר של הuser הנוכחי כמובן

מקווה שזה עונה על השאלה

עריכה:
טעיתי...שכחתי בכלל שה-Id הוא לא בסדר עוקב של פלוס 1.
אנסה למצוא פיתרון אחר, נראה לי שאפשר לשלב עם פיסקת IN.

עריכה 2:

האמת לא הכי הבנתי בדיוק מה אתה צריך לעשות...
בכל מקרה, אני חושב שאתה יכול ליצור טור אחד נוסף שיהיה מסוג text ובו תכניס את כל ה-id'ים שצריך שקשורים למשתמש.
בעזרת שפת צד-שרת תוכל בקלות להכניס id ולהוציא id אחר.

ואחרי שכבר יש לך את כל ה-ID'ים, תשתמש בפיסקת IN.

ציטוט:

בכל מקרה, אני חושב שאתה יכול ליצור טור אחד נוסף שיהיה מסוג text ובו תכניס את כל ה-id'ים שצריך שקשורים למשתמש.

ממש לא הבנתי למה התכוונת במילים "ה-id'ים שצריך שקשורים למשתמש".

כשכתבת:

ציטוט:

הבעיה היא שאני צריך להוציא את השדות בצורה ממויינת (לא לפי סדר לוגי, אלא לפי סדר שהמשתמש קובע).

אז אני מניח שהתכוונת שהמשתמש קובע את ה-ID והוא מאוחסן במסד.
אז אני מציע שתאחסן אותו במסד בתא (מסוג text) שנמצא ברשומה של המשתמש.
עריכה:
שכחתי שהתכוונת בצורה ממויינת ושזה עיקר הבעיה...
בינתיים אני לא מוצא לזה פיתרון עם שאילתה אחת.

מה שכן אתה יכול ליצור טבלה זמנית ולשים בה את כל הפרטים כולל את ה-id וכו' ואז לשלוף מהטבלה הזמנית בעזרת ORDER BY יהיה לך הרבה יותר קל.

אני ממש לא מבין מה אתה אומר.

יש בן אדם אחד ואנונימי שקובע באיזה סדר הרשומות אמורות להיות מוצגות.

עריכה אחרי העריכה שלך:
אני לא רואה איך טבלה נוספת תעזור לי

אני אנסה להסביר לך מה שהתכוונתי...:

יש לך טבלה בשם 'items' ולכל רשומה יש את השדות:
id - מספר ה-id הספציפי של הרשומה.
value - ערך מסויים שקשור ל-item.

מה שאני חושב שצריך לעשות זה להוציא את כל המידע שבטבלה items אל תוך טבלה זמנית, שנקרא לה 'temp_items', בעזרת משפט SQL.
בטבלה הזו יהיו את כל הרשומות, שבהן יש את מספרי ה-id שהמשתמש בחר (לא חייב שזה יהיה לפי הסדר שהמשתמש רוצה, אלא מספיק בינתיים שיהיה רק את ה-id שהוא רוצה בתוך הטבלה הזמנית).

אחרי (או לפני) שיצרת טבלה זמנית, תיצור שאילתה שתוסיף לטבלה הזמנית טור של 'user_choise', כלומר זה טור שקובע את סדר הוצאת הרשומה לפי עדיפות המשתמש (לפי מה שהמשתמש בחר).

בעזרת שאילתת UPDATE אתה מעדכן\משנה את התאים של הטור 'user_choise' בערכים שהמשתמש בחר.
הערכים שהמשתמש בחר נמצאים (או אמורים להיות, או שאתה מקבל אותם בדרך אחרת) לדוגמא במשתנה שפת צד-שרת שנקרא לו data. ואתה יודע איזה id הוא ראשון ואיזה אח"כ לפי המיקום שלו במשתנה.

אח"כ אתה שולף מהטבלה הזמנית את הנתונים בצורה רגילה בעזרת

קוד:

 ORDER BY user_choise

הפתרון הזה יהיה אפילו פחות מהיר מהפיתרון הראשון שהצעתי, להערכתי

לפחות הבנת את הרעיון הכללי...אז לפחות אציע לך רעיון אחר שמתבסס על הרעיון הזה והוא די דומה:

תכניס לטבלה זמנית ריקה [ ששמה 'temp_priority' ] את הנתונים של ה-id של המשתמש, ובטור אחר את הנתונים של סדר העדיפות להוצאת הנתון.
בטבלה הזמנית הריקה הנ"ל יהיו הטורים:
id - ה-id של הרשומה בטבלה items.
priority - העדיפות להוצאת הרשומה.

אח"כ תיצור שאילתת SELECT כמו השאילתה הבאה:

קוד:

SELECT s.* FROM  temp_priority p
LEFT JOIN items s ON (s.id=p.id)
ORDER BY p.priority 

וצודק הפיתרון האחרון שלי [לפני זה שכתבתי עכשיו] באמת מתוסבך וכבד

נראה לי אתה שוכח שהמטרה פה היא יעילות.
אני לא יודע אם שמת לב לכך, אבל גם הפיתרון הנוכחי שלך כבד מאוד,ובאמת שלא מובן לי על איזה id של משתמש אתה מדבר. אין שום משתמשים רשומים או משהו. יש מישהו אנונימי שקובע את הסדר וכל העולם רואה את הדברים בסדר בו הוא קבע.
בכל אופן, לא נראה לי שהבנתת מה אני מנסה לעשות.

ציטוט:

נראה לי אתה שוכח שהמטרה פה היא יעילות.

זה הדבר הכי יעיל שאני יכול בינתיים להציע...
סך הכל מה שצריך לעשות בכלליות זה: ליצור טבלה, להכניס אליה את הנתונים ולפעול באמצעות טבלה זו.
זה הדבר הכי יעיל שהצלחתי לחשוב עליו בינתיים.

ציטוט:

ובאמת שלא מובן לי על איזה id של משתמש אתה מדבר

מצטער זה טעות בניסוח.
התכוונתי לכתוב במקום "את הנתונים של ה-id של המשתמש" את "את הנתונים של ה-id'ים של ה-items בטבלה 'items' שהמשתמש המסויים בחר".
( 'המשתמש המסויים' = 'מישהו אנונימי' לפי ההגדרה שלך בהודעתך האחרונה).

אוקיי. הבעיה עם הפיתרון הזה שהוא עדיין יותר כבד מהפיתרון הראשון שכתבתי בהודעה שפותחת את האשכול, והוא לא מאפשר לי גמישות רבה יותר.
גם בפיתרון הזה אם אני ארצה לעדכן מיקום של איזושהי רשומה אני אצטרך לעדכן את כל הרשומות שאחריה.

אני יכול להמליץ לך על רעיון שאני השתמשתי בו לאחרונה במערכת מסויימת שאני בונה.

הרעיון הוא בעצם להוסיף עמודה בטבלה, שמכילה את התאריך, השעה, הדקה והשניה.
או במילים אחרות, מכילה את הערך שמוחזר מ time().
ואז אתה שולף מהטבלה את השורות בצורה ממויינת, עפ"י העמודה הנ"ל (בצורה יורדת).
(וכל פעם, שמשתמש קובע שמוצר מסויים יהיה בראש הרשימה אתה מעדכן את אותה עמודה בשורה הספציפית של המוצר).

אני לא בטוח אם התכוונת למה שאני חושב שהתכוונת, אבל אם כן אז זה מזכיר לי פיתרון די מלוכלך שאני חשבתי עליו:
בכל שדה place לשים מספרים לא עוקבים(למשל להשתמש בfloat או אפילו בinteger, אבל לא לשים ערכים עוקיבם) ואז כדי להכניס איבר בין שני אברים i ו-j אני אוכל לעשות שהשדה place שלו יהיה ממוצע בין השדות place של i ו-j, ואז יצא לי מספר שיתאים לסדר.
הבעיה היא שיש גבול לדיוק של המשתנים...ולכן בשלב כלשהו יצא לי שתי רשומות עם אותו שדה place ואני אצטרך לנרמל את הטבלה (או לפחות חלק ממנה). אני בינתיים מנסה להימנע מזה.

אוקי עכשיו נפל האסימון, מקודם לא הבנתי כלכך למה אתה מתכוון.
הרעיון שאני הצעתי מתאים אם אתה רוצה בעצם להעלות פריט מסויים שיהיה בהתחלת השליפה,
אבל אתה רוצה שתיהיה אפשרות גם לשים את הפריט בין שני פריטים אחרים.

אני אנסה לחשוב על משהו מתאים.

אם לא כל פתרון צד-לקוח יהיה יותר קל.
אם כן האם זה פר-משתמש? ומה קורה כאשר שני משתמשים ניגשים בו-זמנית לאותם נתונים?

אני לא מבין איך הגעת לשאלה הזאת ממה שאמרתי.

בניסוח פורמלי, מה שאני צריך זה לממש מבנה נתונים ששומר כל פריט מידע ברשומה בטבלה, ושניתן להפעיל עליו את פעולת הכנסה למקום אחרי אלמנט X בסיבוכיות (1)O, והוצאה בסיבוכיות (1)O, ומאפשר לקבל את הערכים בסדר בו הם אמורים להיות בשאילתא אחת.

פתרונות של מבני נתונים לא זורמים טוב עם מסדי נתונים (אחרת כולם היו משתמשים בISAM וזהו).
מהי הבעייה שאתה מנסה לפתור?
בצורה שאתה מציג אין מנוס מ full table scan למרות שזה לא בהכרח דבר רע בטבלאות קטנות...

אם לא צריכים לשמור על הסדר בין הגישות תמיין בשפת צד הלקוח.
אם צריך לשמור על הסדר וזה פר משתמש אז תצטרך להוסיף את מזהה המשתמש כשדה למיון.
אם צריך לשמור על הסדר וזה גלובלי ויש לך יותר ממשתמש אחד אז תצטרך גם לנעול את הטבלה (כל העדכון הארוך בטרנזקציה אחת) ואז מבנה הנתונים הוא הבעייה הקטנה.
אם צריך לשמור על הסדר ויש רק משתמש אחד במערכת אז תלך על עדכון פששוט.

אני כנראה לא מבין את הבעייה אבל כשנתקלים בבעיות מסוג זה תמיד טוב לקחת צעד אחורה ולחשוב ברמת התכנון.

ברמת התכנון אין בעיה. יש לי רשימה מקושרת, אני מאכסן אתה במסד נתונים. אני מחפש דרך לעדכן אותה בצורה החסכנית ביותר שאפשר.

ואולי תסביר לי אחת ולתמיד על איזה סדר גישות ועל איזה מזהה משתמש אתה מדבר? אני לא הזכרתי שום דבר כזה.

לצערי אתה עדיין חושב במונחי מבני נתונים.
מסדי נתונים יחסיים לא עובדים ככה כיוון שהפעולות הן לא בגודל שווה ולכן האופטימיזציות שונות לחלוטין מאלו של אלגוריתמים בזכרון.
מהשאלות שלך אני מבין שיש למערכת רק משתמש אחד שיכול לעדכן את סדר הרשומות הנשלפות והסדר הזה הוא אחיד לכל מי ששלולף את הנתונים האלה.
אם כך אז אין לך ברירה אלא להגדיר שדה order ולעדכן אותו לפי הצורך.

ציטוט:

לצערי אתה עדיין חושב במונחי מבני נתונים.

מאסטר יודַה, לצערי אתה לא יודע מה זה מבני נתונים.
ההפרדה שאתה עושה בין מבנה נתונים לבין נתונים שאני מחזיק במסד הנתונים היא מגוחכת. זה כמו להגיד שאני חושב במונחי משתנים כאשר בעצם אני אמור לחשוב במונחי תאי זיכרון. אם אני מתייחס לאוסף הרשומות כמבנה נתונים, ומגדיר עליהן פעולות, הן מהוות מבנה נתונים..בעסה לך.
דרך אגב, לא שזה משנה, אבל זה בכל זאת מוזר שויקיפדיה מסכימה איתי - "מבנה נתונים הוא דרך לאיחסון נתונים במחשב. האחסון הוא בזיכרון המחשב או בטבלאות בבסיסי נתונים"-קישור.

אבל בכל מקרה, באילו מונחים אני חושב כלל לא רלוונטי.
אם יהיה לך יותר נעים אני מוכן להשמיט את המילה מבנה נתונים והבעיה תישאר בעינה:

יש לי רשומות אשר אמורות להיות מוצגות בסדר מסויים אותו קובע מישהו
אני צריך לאפשר למישהו הנ"ל לשנות את הסדר שבו יוצגו הרשומות,להוסיף ולהוציא רשומות, וכל זאת ביעילות מירבית
אני צריך להיות בעל אפשרות לשלוף את הרשומות בסדר בו המישהו הנ"ל קבע

ציטוט:

מהשאלות שלך אני מבין שיש למערכת רק משתמש אחד שיכול לעדכן את סדר הרשומות הנשלפות והסדר הזה הוא אחיד לכל מי ששולף את הנתונים האלה.

אני שמח שהבנת את זה

ציטוט:

אם כך אז אין לך ברירה אלא להגדיר שדה order ולעדכן אותו לפי הצורך

ייתכן מאוד שאתה צודק, אבל אין שום סיבה מובהקת לכך שמה שאמרת נכון, ולכן ברשותך אני אחפש בינתיים פיתרון אחר.

ציטוט:

מסדי נתונים יחסיים לא עובדים ככה כיוון שהפעולות הן לא בגודל שווה ולכן האופטימיזציות שונות לחלוטין מאלו של אלגוריתמים בזכרון.

אמירה תמוהה ביותר. אני תיארתי איזשהי דרך פעולה של מסדי נתונים, שאיתה אתה לא מסכים? לא. אם כך למה מתייחס "ככה"?
אף אחד לא דיבר פה על ה"גודל" (אני אקח סיכון ואנחש שאתה מתכוון ליעילות) של הפעולות. דובר על עשיית כמה שפחות פעולות, ללא קשר ליעילות הפעולות עצמן.
האופטימיזציות על פעולות במסד נתונים זה נושא מאוד מעניין. יש על כך חומר רב, קורסים רבים בנידון וכו'. זה היה עוד יותר מאגניב אם מישהו היה מדבר על זה בכלל.

אתה המצאת לעצמך פה דיון מעניין על אופן הפעולה של מסדי נתונים ועל ההגבלות בעבודה איתם, כשכל מה שנשאל זה כיצד ניתן לעשות את הפעולות שביקשתי ביעילות מירבית, ובתור שאלה נוספת נשאל איך להוציא את הנתונים בצורה מסודרת אם אני מדמה רשימה מקושרת באמצעות next_id ו-id של הרשומות.

אם השאלה האחרונה מפריעה לך באופן אידיאולוגי אתה רשאי להתעלם ממנה

אני אמנע מכל מה שכתבנו למעלה.

מה סדר-הגודל של הטבלה המדוברת?


אם יש בה פחות מ 20000 שורות אז הפתרון הפשוט הוא הכי טוב:
תגדיר שדה ordering מסוג נומרי.
שליפת הרשימות:

קוד:

select * from items where conditions order by ordering

הכנסה:

קוד:

update items set ordering=ordering+1 where ordering > newitemplace
insert into items values (...newitmplace...)

הההכנסה לרשימה מקושרת תלויה בתוכנה שבעזרתה אתה מתקשר למסד הנתונים.
כל נסיון לשיפור לא ישיג שיפור משמעותי ולעומת זאת יסבך את הקוד.

זה הפיתרון שהצעתי בהודעה הפותחת את האשכול.אבל הסברתי גם למה אני מנסה להימנע ממנו...בטבלה יש הרבה יותר מ-20 אלף רשומות.

איזו היררכיה?
או שמישהו הולך למיין ידנית יותר מ 20000 רשומות.
תרחיב קצת יותר על הנתונים.

האם תמיד נשלפות כל הרשימות מהטבלה?
מהו היחס בין עדכונים לשליפות?

הנתונים ממויינים ידנית, אבל כמובן לא בבת אחת, אלא כל אחד לאחר ההכנסה.
נשלפים כל פעם משהו בסדר גודל של 20 רשומות..וזו גם הסיבה שאני צריך להיות בעל אפשרות לשלוף את הנתונים בצורה ממויינת, כדי שתהיה לי האפשרות להשתמש בlimit וחברים.

אתה גם כנראה תצטרך ליצור אינדקס על השדה כדי לקבל את הנתונים בזמן סביר מה שמייקר עוד יותר את העדכונים.
אם העדכונים לא שכיחים אז זה מחיר שאפשר לשלם.
אם לא אולי ישנה אפשרות לרווח את הסדר בין הפריטים (10, 20, 30) ולתת לעדכון את הממוצע בין שני הפריטים השכנים ובנוסף לדאוג שמידי פעם בשעות פעילות נמוכה של המערכת ירוץ תהליך batch שיסדר את המרווחים

זה בדיוק הפיתרון שהצעתי באחת ההודעות הקודמות...אני מחפש משהו פחות מסורבל

אוקי חשבתי על משהו שלפי דעתי יחסית טוב יותר, אבל אני לא כל כך מבין מה יותר יעיל לכן אתה תגיד לי.

בפיתרון הזה צריך להיעזר בשפת צד-שרת.
בשפת הצד שרת: נגיד שיש לך במערך מסודר את כל מספרי ה-id שהמשתמש רוצה לקבל לפי הסדר.
כלומר שהמפתח של המערך אומר מי להוציא קודם ( 0 במפתח אומר להוציא ראשון, 1 להוציא אחריו וכו'), והערך של המערך מכיל את ה-id.

בצורה הזאת תיצור מחרוזת שתכיל שאילתות SELECT ואחר-כך תבטא אותן לפי המיקומיות שלהן , לדוגמא זו התכולה של המחרוזת:

קוד:

(SELECT * FROM items WHERE id='38') AS 0,
(SELECT * FROM items WHERE id='27') AS 1,
(SELECT * FROM items WHERE id='79') AS 2, 
... etc

וזהו המערך שמכיל את המיקומות של ה-id'ים במפתח, ואת ה-id'ים עצמם בערך:

קוד:

Array:
[0] = 38
[1] = 27
[2] = 79
... etc

אח"כ תשים את המחרוזת בתוך השאילתה הכללית (והקצרה):

קוד:

SELECT (STRING);

במקום המילה "STRING" תשים את המחרוזת שלך.

אח"כ כשאתה שולף את הנתונים, אם תשלוף אותם בצורה של מערך, נדמה לי שצריך לשלוף כמו שלוקחים נתונים במערך דו-מימדי, כי הנתונים יהיו בצורה כזאת לדוגמא:

קוד:

Array:
['0'] [Array:
 ['column1']
 ['column2'] ..etc]
...etc

לגבי השליפה אני לא בטוח איך שולפים כי עדיין לא ניסיתי דבר כזה.

מקווה שזה פיתרון יעיל מספיק...