Возник вопрос. Допустим есть таблица users, в которой инфа о юзерах хранится, и есть другая таблица - в ней храняться некие данные, в числе которых есть поле users_ids, т.е. одной записи в этой таблице может соответствовать несколько юзеров. Как лучше это реализовать?
Я думаю, что следует задать полю users_ids тип serial
и сохранять в этом поле список айдишников... Подскажите, как это лучше сделать, или я на правильном пути? Спустя 3 минуты, 9 секунд (14.12.2010 - 22:51) quickxyan написал(а):
ну я впринципе почти также делал - есть например поле id и создаешь еще одно idd например и в него записываешь id - потом сортируешь данные по дате добавления или еще как вздумаеться и вот он список.
надеюсь это, то что требовалось!
надеюсь это, то что требовалось!
Спустя 6 минут, 12 секунд (14.12.2010 - 22:57) Invis1ble написал(а):
quickxyan
ничего я не понял... ( или это ты меня не понял
ничего я не понял... ( или это ты меня не понял
Спустя 9 минут, 37 секунд (14.12.2010 - 23:07) quickxyan написал(а):
лучше не могу объяснить - просто догадываюсь как сделать, а объяснить не могу 
Спустя 11 минут, 45 секунд (14.12.2010 - 23:19) Invis1ble написал(а):
quickxyan
Видимио, все-таки ты не понял задачу. Меня интересует, как лучше хранить список айдишников и стоит ли вообще это делать (может есть более рациональный способ, хотя я сомневаюсь). Причем тут сортировка?
Видимио, все-таки ты не понял задачу. Меня интересует, как лучше хранить список айдишников и стоит ли вообще это делать (может есть более рациональный способ, хотя я сомневаюсь). Причем тут сортировка?
Спустя 3 минуты, 54 секунды (14.12.2010 - 23:23) quickxyan написал(а):
ну я просто дописал если вдруг нужна очередность. вобщем мы не понимаем друг друга) - извини, что не смог помочь.
Спустя 1 минута, 45 секунд (14.12.2010 - 23:24) kovaldm написал(а):
Просто храни айдишники через запятую.
Спустя 1 минута, 53 секунды (14.12.2010 - 23:26) quickxyan написал(а):
прикольный выход из ситуации)
Спустя 8 минут, 11 секунд (14.12.2010 - 23:34) Invis1ble написал(а):
kovaldm
тоже вариант =)
Вобщем вопрос пока остается актуальным, т.к. хотелось бы услышать мнение экспертов
тоже вариант =)
Вобщем вопрос пока остается актуальным, т.к. хотелось бы услышать мнение экспертов
Спустя 25 минут, 43 секунды (15.12.2010 - 00:00) Invis1ble написал(а):
И еще: если записывать айдишники как строку текста, то будет ограничение по длине в 65535 символов, насколько я понимаю
UPD. Тупанул я, LONGTEXT надо юзать
UPD. Тупанул я, LONGTEXT надо юзать
Спустя 51 минута, 45 секунд (15.12.2010 - 00:52) Invis1ble написал(а):
Блин, serial - оказывается это bigint usigned not null =) а я думал, что можно сериализованный массив хранить в таком поле
Спустя 41 минута, 34 секунды (15.12.2010 - 01:33) aH6y написал(а):
Invis1ble
Создаёшь таблицу:
note userid
запись user
запись user
запись user
и добавляешь в таблицу к любой записи любого юзера.
Таким формированием таблицы ты в любой момент сможешь добавить, удалить иль изменить нужный id в записи и наоборот.
Создаёшь таблицу:
note userid
запись user
запись user
запись user
и добавляешь в таблицу к любой записи любого юзера.
Таким формированием таблицы ты в любой момент сможешь добавить, удалить иль изменить нужный id в записи и наоборот.
Спустя 22 минуты, 27 секунд (15.12.2010 - 01:56) Invis1ble написал(а):
этот вариант не подходит из-за избыточности
Спустя 2 часа, 6 минут, 50 секунд (15.12.2010 - 04:03) inpost написал(а):
А если связку делать не из второй, где хранятся ай-дишники первой! А из первой, где хранится ай-дишник второй таблицы. То есть у юзера будет прописан, к какой id ячейки он относится! Так будет удобнее и рациональнее, на мой взгляд.
Спустя 40 минут, 27 секунд (15.12.2010 - 04:43) Invis1ble написал(а):
inpost
дело в том, что юзер может относиться сразу к нескольким записям из другой таблице, поэтому разницы нет - в любом случае нужно сохранять список айдишников. Если б он мог относиться только к одной записи, то тогда да - правильней было бы сделать как ты предложил.
дело в том, что юзер может относиться сразу к нескольким записям из другой таблице, поэтому разницы нет - в любом случае нужно сохранять список айдишников. Если б он мог относиться только к одной записи, то тогда да - правильней было бы сделать как ты предложил.
Спустя 34 минуты, 45 секунд (15.12.2010 - 05:18) inpost написал(а):
А смотри, какая длина будет ай-дишников, если хранить у юзера? И если во второй таблице (как я понимаю, тут может более тысячи пользователей быть, а что с первым вариантом, пользователь тоже будет к тысяче строк привязан из второй таблицы?)? Они соединяться хаотично будут, или как-то группироваться?
Спустя 4 часа, 17 минут, 5 секунд (15.12.2010 - 09:35) linker написал(а):
Если к одной записи инфы, могут ссылаться несколько пользователей, то как эта связь называется? И как она реализовывается?
Спустя 1 час, 33 минуты, 41 секунда (15.12.2010 - 11:09) Семён написал(а):
Хранить список id в 1 ячейке - сверх-глупость.
Спустя 2 часа, 10 минут, 32 секунды (15.12.2010 - 13:19) SlavaFr написал(а):
да тут ведь обычный способ для разбива N to N отношений.
Просто создаеш дополнительную таблицу которая содержит ID Юзера и ID другой таблицы. Мне кажется @aH6y какраз это и имел в виду.
Просто создаеш дополнительную таблицу которая содержит ID Юзера и ID другой таблицы. Мне кажется @aH6y какраз это и имел в виду.
| Цитата (kovaldm) |
| Просто храни айдишники через запятую. |
Проблемы при таком варианте будут заметны при малейшем изменении в структуре таблиц или просто при желании найти более мение быстро в таком поле определенное id или несколько id-шек сразу.
Спустя 5 часов, 42 минуты, 48 секунд (15.12.2010 - 19:02) Invis1ble написал(а):
inpost
| Цитата |
| как я понимаю, тут может более тысячи пользователей быть, а что с первым вариантом, пользователь тоже будет к тысяче строк привязан из второй таблицы? |
ага. Связь многие ко многим (вроде так это называется).
| Цитата |
| Они соединяться хаотично будут, или как-то группироваться? |
хаотично, связи могут быть какие угодно
linker
linker
| Цитата |
| Если к одной записи инфы, могут ссылаться несколько пользователей, то как эта связь называется? И как она реализовывается? |
подскажи, я в смятении
наверно, многие к одному.. но мне вродебы надо многие ко многим SlavaFr
Если я правильно понимаю, то при такой реализации получится:
для 1000 юзеров, каждый из которых относится к 1000 записей = 1000*1000 - итого миллион записей, а ведь это только для 1000, а если будет больше? Если я неправильно понял, уточни структуру таблицы.
| Цитата |
| найти более мение быстро в таком поле определенное id или несколько id-шек сразу |
это я уже придумал, как реализовать, например мне нужно будет найти запись с id 15 - LIKE '%|15|%'
Спустя 1 час, 16 минут, 13 секунд (15.12.2010 - 20:18) Invis1ble написал(а):
Щас посоветовался со своим знакомым программером, он тоже говорит, что лучше отдельную таблицу создать... Наверно так и сделаю
Всем большое спасибо за советы и проявленный интерес!!!
Всем большое спасибо за советы и проявленный интерес!!!
Спустя 17 часов, 41 минута, 52 секунды (16.12.2010 - 14:00) SlavaFr написал(а):
| Цитата (Invis1ble @ 15.12.2010 - 17:18) |
| Щас посоветовался со своим знакомым программером |
можеш нас всех записать в список знакомых программистов.
| Цитата (Invis1ble @ 15.12.2010 - 16:02) |
| для 1000 юзеров, каждый из которых относится к 1000 записей = 1000*1000 - итого миллион записей, а ведь это только для 1000 |
А если бы ты без референциальной таблицы делал, то эти записи болтатлись бы в твоем техтовом-поле занимая при этом практически такойже размер. Но это даже не так страшно, как то, что только определенная часть техтового поля может быть индексиерованна для быстрого поиска и при длинных значениях база будет вынуждена заходить в каждую такую строчку и проверять ее значение, что уже при 1000 строчках начнет перегружать базу.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль