Вопрос такого плана:
есть некоторые сущности, между которыми есть нечто общее. Ну допустим элементы для построения дома. Общее у них вес, длина, ширина, высота. И разное: у одного типа элементов допустим предельная нагрузка на сжатие, у другого горючесть, у третьего цвет. Можно все элементы затолкать в одну таблицу и часть полей не использовать для каждого типа. Или сделать отдельно общую таблицу с общими свойствами и отдельно по каждому типу дополнительные таблицы с полями и ссылками на основную. Как лучше?

> _REA  (17.06.2010 14:47:00)  [0]

И то можно и то, но я за одну таблицу, к ней запросы легче делать, не надо
кучу UNION

Спасибо, мне тоже такое решение показалось проще.

> И то можно и то, но я за одну таблицу, к ней запросы легче
> делать, не надо кучу UNION

вот UNION там вообще ни в пень, мож речь о JOIN ?

по сабжу:
я обычно предпочитаю таки вариант 2

> Правильный$Вася  (17.06.2010 15:44:03)  [3]

По предложеному алгоритму именно UNION, ведь предложено создать кучу таблиц,
которые отличаются некоторыми дополнительными полями, а не таблиц
"справочников", так не с чем соединяться, только объединять запросы.

> Правильный$Вася  (17.06.2010 15:44:03)  [3]

Пример
Tbl1Тип1
Id, название, вес
Tbl2Тип2
Id, название, вес, цвет
....

На практике, ИМХО, чаще получаются промежуточные варианты между первым (простота) и вторым (универсальность). Иногда из-за 1% сущностей неохота городить отдельные структуры, а иногда разница настолько велика, что впихивать в одну таблицу вроде и смысла то нет, кроме ИД ничего общего.

> Anatoly Podgoretsky ©   (17.06.10 16:36) [4]

неа, автор говорил об > отдельно общую таблицу с общими свойствами и отдельно по
> каждому типу дополнительные таблицы с полями и ссылками
> на основную

а это при работе с конктерным элементом - JOIN
а все скопом, конечно, без UNION

> Sergey13  (17.06.2010 16:59:06)  [6]

Вариант, который я привел, без общего ИД, это просто разные не связаные
таблицы, как в постановке автора.

> неа, автор говорил об > отдельно общую таблицу с общими
> свойствами и отдельно по

Если так, то это называется 1 к 1, смысла не имеет, хотя и входит в нормализационную теорию (как курьез).

> смысла не имеет, хотя и входит в нормализационную теорию

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

у этих сущностей кроме общих атрибутов типа длины  цвета и запаха есть еще одно (и самое главное) общее: это всё "элементы для постройки дома"

одна таблица.

> Правильный$Вася  (17.06.2010 20:01:10)  [10]

Да кто же предлагает забивать кеш и при одной таблице, так если таблицы то
таблицу цвет использовать не будем, а если одна, то ОБЯЗАТЕЛЬНО будем
использовать поле цвет.
Я пока знаю только одно обоснованное примение связи 1-1, это старинные СУБД,
которые имеют серьезные ограничения на количество столбцов. Тут просто в
одну таблицу не поместить все данные, приходится использовать несколько.

> Да кто же предлагает забивать кеш и при одной таблице, так
> если таблицы то таблицу цвет использовать не будем, а если
> одна, то ОБЯЗАТЕЛЬНО будем использовать поле цвет.

невнятный поток слов
по-русски можно?

>>Anatoly Podgoretsky ©   (17.06.10 15:21) [1]
>>но я за одну таблицу

Поэтому, кто такой Эдгар Кодд - знают все. А кто такой Толя Подгорецкий?

>>Или сделать отдельно общую таблицу с общими свойствами
>>и отдельно по каждому типу дополнительные таблицы с полями и
>>ссылками на основную.

Не надо ссылок на основную. У всех таблиц - одинаковый первичый ключ.

SELECT
 *
FROM
 MainTable MT, AdvTable1 AT1
WHERE
 (MT.ID = 1) AND (AT1.ID = 1)

Нормализацию еще никто не отменял. Делай общую таблицу с общими свойствами, и отдельно, по каждому типу - дополнительные таблицы.

> Строитель   (22.06.10 19:00) [14]


> Поэтому, кто такой Эдгар Кодд - знают все.

Кто такой Птолемей знают все, а потому Земля у центре усево


>
> SELECT
>  *
> FROM
>  MainTable MT, AdvTable1 AT1
> WHERE
>  (MT.ID = 1) AND (AT1.ID = 1)

а у кого нет таких свойств - идут лесом! Я - за, нефик, лишние.

"Довольно часто встречаются приложения, построенные с использованием универсальных моделей данных для максимальной гибкости, и приложения, построенные так, что они мешают работе. Например, хорошо известно, что можно представить любой объект в базе данных используя только четыре таблицы:

create table objects (oid int pimary key, name varchar2(255));
create table attributes (attrid int primary key, attrname varchar2(255),
 datatype varchar2(25));
create table object_attributes (oid int, attrid int, value varchar2(4000),
 primary key (oid,attrid));
create table links (oid1 int, oid2 int, primary key (oid1, oid2));

Но как такая модель работает ? Простой запрос select first_name, last_name from person трансформируется в соединение трех таблиц с аггрегированием, более того, если имеются атрибуты NULLABLE - в таком случае может не быть строки в таблице object_attributes для некоторых атрибутов, - возможно, возникнет необходимость использовать внешнее соединение, которое может исключить оптимальные планы запросов из рассмотрения.

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

(с) Том Кайт "Эффективное проектирование приложений Oracle"