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

Кр4 суть такая: таблица например USER в ней должно быть куча полей (fields) например password, icq, email и так еще каких 30 штук.

Вопрос: как лучше создать таблицу? делать для каждого значения отдельное поле или делать поля например такими: info, info2

а в скрипте писать так:



Как лучше работать? Делать для каждого значения отдельное поле? Если так делать, то с базой данных проблем потом не будет когда будет 1000+ пользователей в сети? Лаги не будут? (в mysql запросах в конце стоит везде LIMIT 1 ну и конешно же where user=".$info['user']."

Это сообщение отредактировал(а) fleetboss - 6.8.2009, 15:49

делать для каждого значения отдельное поле

http://podgoretsky.com/ftp/Docs/Classics/Gruber/unde_sql.pdf

название атрибута должно отражать его суть. 
есть исключения из правил, но это не ваш случай.

Необходимо делать для каждого значения свое поле в БД (атрибут), при необходимости нужно производить нормализацию БД, определять сущности (таблицы), вообще без нормализации БД похожа на мусорный ящик, ведь нельзя засунуть все в обну таблицу. Для построения концептуальной модели используй ERWin, или DBDesigner.   

если значения всегда одинаковые, то однозначно "каждой блошке по отдельной дорожке"... 

Но у меня есть проекты где параметры не только не постоянны но и могут быть разными.. Для этой цели я использую принцип который подсмотрел у Joomla, т.е. в одном поле перечисляются название параметра и значение через "\n"

да и обрабатывать не сложно... например так


Это сообщение отредактировал(а) Gold Dragon - 27.8.2009, 11:10

Присоединённый файл ( Кол-во скачиваний: 12 )
 _________1.gif 3,79 Kb

Для таких целей подойдет EAV
и не обязательно (а даже вредно) хранитиь название и значение в одном поле.

А если кратко и на русском что это?

поясни, особенно "вредно"

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

и зачем столько лет разрабатывалась реляционная алгебра, индексы, нормализация, оптимизация, хайлоад...
баловство это все и ни к чему.

Добавлено через 2 минуты и 49 секунд
Simpliest, не, ну если он хранит сериализованные, пусть и таким доморощенным способом, данные, то разумеется, там все скопом.
Вот только к какое это все имеет отношение к базам данных вообще и к первоначальному вопросу - в частности...

EAV это один из методов хранения информации с переменным числом полей

Т.е. структура хранится не в одной какой-то таблице, а в нескольких.

Простой пример:

Есть таблица для строковых данных
Есть таблица для дат
Есть таблица для чисел

все они имеют одинаковую структуру
id, id_rec, att_name, att_value

Отличаются лишь типом поля att_value.

Фактически все данные из разных таблиц с одинаковым id_rec это у нас одна запись обычной таблицы.
Таким образом если мы захотим добавить 2й,3й, 5й телефон к записи пользователя "Вася" нам не надо будет менять структуру таблиц и запросов. Мы просто добавим в таблицу строковых данных запись вида

xx, id_пользователя_Вася, телефон5, 1-11-111-11

Simpliest, Сначала подумай на тему почему добавить поле в табличку это плохо, затем подумай на тему почему сделано так что добавлять поле в табличке  оказалось плохо, а потом подумай как ты будешь избавляться от того, почему плохо, в рекомендуемой тобой ЕAV.

Поясняю.
Когда у тебя хранится несколько атрибутов в одном поле, как ты указал, то ценность базы близка к нулю.

Ты ни нормального поиска не произведешь, ни агрегационные функции не сработают, ни группировка - ничего. 

Плюс ты не сможешь использовать индексы, а значит работать все будет очень медленно.

Добавлено через 3 минуты и 50 секунд
Zloxa, сначала подумай на тему, где используется EAV.
Потом подумай на тему, его преимуществ.
Потом подумай на тему, его недостатков.

А потом пойми, что люди умнее тебя 

Hint: Обычно денормализованные таблицы выгоднее по скорости работы.
Hint2: Обычно нормализованные таблицы более гибкие.

Simpliest, Через это таки надо пройти

Zloxa, вот возьмите и пройдите... куда-нибудь мимо, с дурацкими поучениями.
Я через это прошел 6ть лет назад.

Но некоторые люди не взрослеют и наивно полагают:

•  что они умнее других. 
•  что простота - это зло. 
•  удобство - это зло. 
•  гибкость - это зло. 
•  преждевременная оптимизация - это зло.

Учитесь жить своими мозгами, а не заученными штампами. А потом подсовывайте мне топики вашего авторства и сомнительного содержания.

Я года четыре назад пытался в очередной раз городить этот огород.

Только выводы сделал совсем другие
* Я не умнее других, и старшие товарищи таки оказались правы
* Решения простые в виде идеи могут оказаться не столь просты в реализации. Иной раз достаточно лишь подумать.
* Удобство - понятие весьма относительное
* Гибкость почти всегда приводит к потере прочности
* никакая оптимизация не компенсирует кривизну архитектуры

Почему вы считеате что alter table add column менее просто и менее гибко нежели insert into attributes_table?

Потому что вы рассматриваете решение в виде сферического коня в вакууме и пытаетесь дать оценку методу.

Если нужна система с редким вмешательством квалифицированных специалистов, но с возможностью донастройки в процессе работы.
То EAV более устойчив к "глупым" пользователям. Его ниша это возможность рассширенного аттрибутирования модели "неподготовленными" людьми.

Потому что используя ALTER TABLE я могу вообще убить нахрен всю систему одним движением руки, а при помощи INSERT это сделать сложнее.

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

Вот и я примерно о том же. В этом топике очевидно, что у ТС нет достаточного понимания  ER модели, и это, пожалуй единственная проблема которая перед ним стоит. Ваш совет реализовать EAV средствами РСУБД носит явно деструктивный характер, т.к. ТС не может оценить недостатков этой модели, в то время как достоинства для нуба кажутся очевидными. До тех пор, пока в ответ на вопрос чем insert предпочтительнее alter table не прозвучит разумного  ответа, мол DDL не журналируется, говорить о преимуществах EAV не имеет смысла, тк. это, пожалуй, единственное преимущество этой модели. Ничего в этом топике не говорит о том, что действительно следует воспользоваться этим преимуществом.

Печаль, вы меня утомляете. 

Я не собираюсь вам доказывать, что вы глупее меня. Оставлю это вам, поскольку верю - вы справитесь.

•  1. Я отвечал не топикстартеру а Gold Dragon. На его хранение нескольких атрибутов в одном поле.
•  2. Пойдите почитайте хотя бы wiki о том, где удобно EAV. Да, я об этом тоже не упомянул в контексте топика поскольку считал, что люди неглупые - сами прочтут. Вижу - ошибался.
  В частности - разреженные массивы данных вы можете хранить в чем угодно, но когда у вас на таблицу из сотен полей будет использоваться от силы десяток-другой, то ваше упрямство поставит вас в неудобную позу.
•  3. DDL отлично журналируется вместе с другими запросами, буде мы используем не голую БД, а конкретное приложение.
•  4. Вы упускаете тот момент, что в случае EAV вопрос связей между сущностями ложиться не на БД, а на приложение. И это не недостаток, это особенность модели.
  И именно ваше незнание привело вас к тому что вы получили ручкой граблей по лбу и теперь регулярно в каждом топике плюетесь в сторону EAV.

За сим я откланиваюсь.

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


Это сообщение отредактировал(а) Zloxa - 3.9.2009, 14:41

Ипатьев, дружище, знаешь... прочитал ответ и понял одно... все дураки а ты умный.. Без обид, но(!) Наверное люди тут на форуме общаются с целью получения знаний? Наверное у всех есть какой-то опыт в создании проектов? И уж точно что люди хотят слышать ответы или рекомендации или замечаний... А что ты написал? Ну что ты прогрессивный и что все остальные динозавры?  Извини что так резко, но если уж приводишь что-то, то аргументируй примерами и желательно своими... 

а теперь по теме.. я всего-лишь предложил вариант решения.. задачи то ведь бывают разные 
Например, у меня в проекте примерно около 100 модулей, которые имеют собственные характеристики.. Каждый объект может иметь любое сочетание этих модулей. Это поле только содержит данные в формате Ключ->Значение... Никакой поиск по этим полям не ведётся, да и он не нужен... Есть другое индексированное поле для таких целей  Так что выгоднее найти запись по индексу и достать данные из поля чем построить абсолютно никому не нужные 100 таблиц с данными и ещё таблицу согласования 

Мой опыт подсказывает, что те случаи, - когда EAV обычно уместно, - не имеют никакой проблемы с конкурентным доступом на редактирование. Поскольку редактирует такие сущности обычно 1 человек. В исключительных же случаях простой блокировки более чем достаточно (да механизм придется прописывать ручками в приложении).

Хотя мой опыт тоже может ошибаться.

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

P.S. хотя тот же MSSQL, Oracle, Firebird, да и MySQL последних версий дают возможность весь интерфейс работы с сущностями заложить в БД в виде хранимых процедур, триггеров и view.
Тогда для конечного приложения это будет мало отличаться от работы с обычной таблицей.