Є список, наприклад, користувачів, що зберігаються в таблиці: users.id = 1, users.id = 2. users.id = 193
Припустимо, користувач може мати друзів - інших користувачів, тобто id = 1 дружить з 2, 8, 39, 43.
Не можу вирішити, як же краще зберігати ці зв'язки?
Перше, що спадає на думку - це створити таблицю М-к-М, users_friends і зберігати
u_id - f_id, типу
1 - 2
1 - 8
1 - 39
1 - 43
Але тоді виходить, що передружіть сотню з сотнею вийде 100 * 100 INSERToв, а вже потім оновлювати це - взагалі труба, здається.
Друге - це зберігати в users рядок friends і зберігати в ній список id1.friends = (2,8,39,43).
Але тоді, щоб дізнатися, у ково той чи інший користувач в френда доведеться вибирати за допомогою LIKE, як я розумію? Але як уникнути, щоб LIKE 12 Не вибрало LIKE 123, прив'язуватися до розділювачам?
Підкажіть, як зазвичай надходять для вирішення такого завдання.
Соррі, якщо туплю.
UPD. Шановні, сорри, що без персонального відповіді кожному - але спасибі всім велике, все зрозумів, буду діяти за статутом. Дякуємо!
Можна вчинити так: зберігати id друзів, розділивши «|». Тоді, наприклад, запит «SELECT * FROM users WHERE freinds LIKE '% | 123 |%'» вибере тільки тих, у яких в друзях користувач з id = 123.
Ось тільки спосіб поганий тим, що красивого редагування і / або видалення не вийде.
Ви уявляєте, на що перетвориться пошук Friend Of для сервера? Він же подихати буде кожен раз, якщо мемберов буде хоча б кілька тисяч
Хм. Що то ви, шановні не те радите.
Якщо є рядок _1,2,3,4_, то FIND_IN_SET проруліт чудово.
Але це якщо оочень хочеться застосовувати саме такий мтод.
В MySQL є тип даних SET. думаю він підійде для такого завдання, якщо число друзів - не більше 64.
Інакше, при правильній організації даних, подружити 100 користувачів зі 100мі - це не 10.000 рядків, а 5.000. Якщо в середовищі кожен юзер явядется френдом здебільшого осталтних користувачів, то можна вважати, що за замовчуванням всі є френдами, а зберігати інформацію про НЕ-френда.
Якщо матриця дружності заповнена не сильно, тобто у кожного користувача в френда не більше 10% всіх користувачів, то можна спробувати використовувати алгоритми розріджених матриць.
Цікаво, скільки ще способів вирішити цю задачу "через жопу" буде запропоновано?
У поставленому завданню - перший варіант (з ключем по u_id, звичайно) і ніяк інакше. Операції зміни даних по такій таблиці буде проходити миттєво.