Как лучше хранить данные в БД?

Question

[shapeshifter08]

Есть таблица members с множеством полей.
Сегодня решил сделать одну функцию для своего форума — дополнительные поля профиля.
Передо мной встал вопрос: как хранить данные?
Вариант 1:
Создать отдельную таблицу и посредством LEFT JOIN выводить дополнительные данные.
Вариант 2:
Создавать поля в уже существующей таблице members

Что лучше (менее тяжелое для базы)?

Answer 1

[EugeneOZ]

Удивляют и вопросы и ответы. Особенно про «опросил бы клиентов». Это ж ух!..
ru.wikipedia.org/wiki/%D0%9D%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%84%D0%BE%D1%80%D0%BC%D0%B0 — читайте это.

Comments

[Hint]

В реальных условиях часто приходится делать денормализацию ради оптимизации.

Answer 2

[RubtsovAV]

В вашем конкретном случае оптимальным вариантом было бы первое решение с джойнами. Об этом способе оптимизации БД уже давно известно, но от себя все же хочу добавить, что не стоит впадать в крайности и плодить кучу джойнов — достаточно будет одного. Т.е. создание отдельной таблицы для каждого поля (как например сделано в друпале) наоборот замедлит работу БД.
ЗЫ. Есть еще вариант сделать один столбец в таблице и хранить в нем дом поля в виде json, но в вашем случае вряд ли такой способ будет оправдан.

Comments

[RubtsovAV]

«дом поля» — доп.поля (автозамена малин)

[shapeshifter08]

Я не хочу создавать поле с массивом данных, т.к. по ним будет сложно осуществить выборку/поиск.

[RubtsovAV]

Причем в эту доп.таблицу писать только редко требуемую инфу, а в основной же хранить, которые нужны часто (например листинг). Если же доп.поля будут нужны постоянно, то лучше второй вариант, т.к. джойнов будет нагружать только «утяжелять»

Answer 3

[max7 M7]

Я стараюсь при разработке структуры базы придерживаться философского «никаких UPDATE'ов — только INSERT'ы». Это делает базу значительно более гибкой. Но соответственно увеличивается количество и сложность (JOIN'ы) SELECT'ов. Если есть запас по производительности, то конечно «вариант 1».

Comments

[shapeshifter08]

В моем случаи нужен компромисс, т.к. форум у клиентом может быть на лайт-хостинге, а может и со своим сервером.

Answer 4

[ComodoHacker]

Я бы опросил клиентов, какие поля они хотели бы добавить. Самые востребованные добавил бы в основную таблицу, а фичу «произвольные поля» закинул бы в дальний TODO-лист и забыл.

Answer 5

[egorinsk]

Вариант 2 — если вам надо часто добавлять поля, то учтите, что добавление поля — это фактически создание второй копии таблицы (т.е. долго). Также, при большом числе полей растет объем таблицы, ухудшается время доступа.

Что касается вариата 1, рассмотрите также вариант выбирать записи без JOIN, а 2 запросами — MySQL на джойнах может неэффективно работать (к сожалению, точнее сказать не могу, это надо проверять на практике).

Я бы лично сделал вариант 1, но с кешированием в каком нибудь key-value storage.

Comments

[shapeshifter08]

Суть в том, что форум делается для клиентов, а не лично для меня, поэтому кто-то может не создавать поля, а кто-то может десяток создать.
Плюс ко всему я рассматриваю возможность вывода данных в теме, где и так много запросов и не хотелось бы из-за доп. полей лишний раз загружать базу.

[egorinsk]

Добавление поля — это ALTER TABLE — это медленная операция на больших таблицах. Ее вообще нельзя делать через веб-интерфейс. Потому используйте EAV, или как это называется, таблицу вида record_id/name/value.

Answer 6

[4ikist]

Вторая таблица содержит:
id | member_id | field_name | value

Comments

[shapeshifter08]

Скорее думал сделать member_id | field_1 | filed_2
Где filed_x название поля и в нем значение поля, дабы не создавать множество записей для разный полей.

[RubtsovAV]

В таком виде будет опять же сложно производить например поиск по базе, да и в производительности довольно спорный момент.

[RubtsovAV]

Мне видится это скорее как 1ый вариант + 2ой вариант (для доп.таблицы).

[Hint]

Скорее думал сделать member_id | field_1 | filed_2

Например, есть поле «сайт». У меня ведь может быть несколько сайтов. В вашем случае подобное не предусмотрено. На том же хабре можно указать несколько вариантов одного типа.

[RubtsovAV]

А в чем проблема собсно?
member_id | site_1 | site_2 |…

[RubtsovAV]

Да и можно одним полем обойтись, достаточно подумать над форматом хранения: для урлов сайта можно просто добавить разделитель # между адресами.

[RubtsovAV]

либо тот же json или csv зависит от случая

Answer 7

[RubtsovAV]

shapershifter08 как раз про такой вариант грил

Comments

[RubtsovAV]

Это должен был быть комментарий к предыдущему ответу… Паромах нуля ссылкой, а удалить нет такой возможности :(

Answer 8

[shapeshifter08]

Все спасибо за ответы.