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

Кр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 это сделать сложнее.

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