Пусть есть две сущности A (три атрибута: a1 - строковый (100 символов), a2 - целое число, a3 - не важно) и B (три атрибута: b1 - строковый (100 символов), b2 - целое число, b3 - не важно). Например, A и B - это те же товары в каталоге, и информацию обо всех товарах мы решаем хранить в одной таблице (вместо создания отдельной под каждый тип товара) с полями a1, a2, a3, b1, b2, b3, type (type принимает значение A или B).

Не знаю, как мне пришла в голову такая мысль, но почему в данном случае не сделать таблицу из пяти столбцов вместо семи?

Заголовок отношения будет таким: (a1b1, a2b2, a3, b3, type) или проще (f1, f2, f3, f4, type). Т.е. в последнем случае мы вовсе избавимся от осмысленных названий атрибутов. А если задуматься, то зачем они вообще, если пользователь все равно получает псевдонимы (SELECT f1 AS ...)? А осмысленные названия можно хранить где угодно, в голове, другой таблице, программе. И зачем под одинаковые по типу атрибуты в данной модели делать разные столбцы?

С одной стороны, смотрится дико, с другой - мучают два вопроса выше. Вправьте мозги, если не трудно :)

P.S. А может все-таки это используется и я об этом просто никогда не слышал? :))

Senya_L1 таблица на всю базу, в ней 3 столбца: (EntityID, Param, Value). Первый столбец типа int/bigint, остальные varchar.

Это уже EAV, и его действительно нужно выкинуть на помойку.

БредятинаВот, "споткнулся" на пятом "кортеже":) Это имя Петрова. Тоже строка (предположим, атрибут a4 первой сущности из Вашего примера). А что мне во второй колонке записать? В первой записи - это год рождения Петрова.

Нет, для имени - отдельный столбец. Тоже строковый. Но если потом вдруг найдется еще один строковый атрибут у другой модели, то можно будет так же их "скрестить" в этом столбце. В общем, как обычно: одна строка - один объект.

БредятинаВам, наверное, нужно посмотреть преобразования Тарена, это, во-первых, перспективное направление, по мнению Дейта, а во-вторых, в русле Ваших идей:)
Что это такое, если не секрет?

И это не русло моих идей, а просто мысль, которая каким-то образом забрела в мою голову :) А где поделиться мыслями? Конечно на форуме, а то еще в реальной жизни на костре сожгут.

Бредятина,

БредятинаНе ясно. Почему отдельный? Почему для фамилии человека и названия организации - один "столбец", а для имени человека - другой? Что значит "как обычно: одна строка - один объект"?
Потому что в таком случае выбрать человеков простым SELECT'ом не удастся. А когда всё в одной строке, то просто перечисляем нужные поля: SELECT f1, f3, f8 FROM... И не важно, что для другой сущности мы будем делать SELECT f1, f4, f8 FROM...

БредятинаОбратите внимание, что с таким вольным обращением с терминами понять будет трудно Вы использовали для простого примера: "сущность", "атрибут", "таблица", "отношение", "модель", "объект", "строка" - это, как минимум:)
Да, виноват. Объекты тут вообще не при чем.

SeZukaЕсли речь идет о товарах разных типов и их атрибуты по количеству и типу совпадают, то зачем их хранить в отдельных таблицах? А если же вы хотите объединить в одной таблице товары и услуги, у которых явно разное количество атрибутов, можно, но смысл???

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

Вот пример:
Пусть у нас есть Матрешки (М), Люстры (Л) и Сотовые телефоны (Т). Как и любые товары, они все обладают ценой, а еще для каждого товара может указываться дата добавления в каталог и дата последнего обновления информации о товаре. Посмотрим на уникальные атрибуты:

М: вложенность матрешек (целое число), высота самой большой (целое число).
Л: количество лампочек (целое число), максимальная мощность лампочки (целое число), хрустальная (да/нет).
Т: вес (целое число), фотокамера (есть/нет), сенсорный дисплей (да/нет), диагональ (не целое).

Делаем одну большую таблицу из 9 (атрибуты товаров) + 1 (цена) + 1 (дата добавления) + 1 (тип товара, М, Л или Т) = 12 столбцов.

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

вложенность матрешек + количество лампочек + вес = a (обозначаем все три атрибута буквой "a").
высота самой большой матрешки + максимальная мощность лампочки = b.
хрустальная + фотокамера = c.
сенсорный экран = d.
диагональ = e.

После таких переобозначений пример таблицы может быть таким:
шапка: (id, a, b, c, d, e, price, created_at, type)
данные: (1, 6, 20, -, -, -, 300, '30-11-2010', 'М'), (2, -, 130, да, нет, 3.5, 5000, '29-11-2010', 'Т') и т.д.

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

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

Спасибо, интересная информация. Только вот реализаций этого эффективного хранения что-то пока нет. Но мои рассуждения намного примитивнее, чем там :)

LSVСделать группу EAV-таблиц по типам параметра: Целое, Флоат, Дата, Строка, Boolean.
Всегда заранее известно, какого типа параметр, поэтому искать нужно в конкретной таблице.

Про EAV здесь и слышать не хочу!

---------------------------------------------------------------------
И еще несколько мыслей относительно темы:
1) При увеличении количества товаров будет расти и количество различных атрибутов, но т.к. типов заведомо довольно мало, то количество столбцов в таблице расти будет гораздо медленнее. А может и вовсе хватит двадцати, которые можно задать в самом начале, а потом только решать, какой атрибут куда лучше "положить".

2) Не хочется доводить идею до полного абсурда, но в такой таблице можно хранить и вовсе посторонние (логически) вещи, например, новости (уж пара-тройка тектовых полей найдется). Если толковые СУБД и вправду умеют экономить место на NULL-значениях полей, то большого проигрыша в дисковом пространстве мы не получим (или получим?). В любом случае, проигрыш будет в голове разработчика такой базы.

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

MasterZivНе так и дико смотрится. Это один из подходов, применяемых при ORM.
Это (если интересно) описано подробно в документации по Hibernate.
Пока писал предыдущее сообщение, совсем забыл про ваше. Я с Hibernate, к сожалению, не знаком. Можно попросить ткнуть меня в раздел документации, где про это написано?

SeZuka,

SeZukaСуть вашей идеи понятна и из первого поста, на что я вам и ответил: можно, а смысл?
А смысл тогда хранить одинаковые по типу атрибуты различных товаров в разных столбцах таблицы?
Все равно при выборке делать SELECT с перечислением заведомо известных для данного типа товара полей.

SeZukaНу если они так умеют, то к чему затея с объединением полей??? Запихайте в эту таблицу еще производителей товаров, покупателей, сотрудников и делайте для каждого типа записи свои поля, СУБД сэкономит вам место. Да и быстродействие будет выше, ведь будет всего одна таблица вместо кучи ненужных :)

Тогда нельзя будет сделать связи между товарами и покупателями (стандартными простыми средствами). Но это далеко не единственная причина.

В общем, мнения других людей я услышал. И ответ на мой вопрос: "Можно, а смысл?" :)