Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Одна таблица или несколько?

_REA © (2010-06-17 14:47:00)
Вопрос такого плана:
есть некоторые сущности, между которыми есть нечто общее. Ну допустим элементы для построения дома. Общее у них вес, длина, ширина, высота. И разное: у одного типа элементов допустим предельная нагрузка на сжатие, у другого горючесть, у третьего цвет. Можно все элементы затолкать в одну таблицу и часть полей не использовать для каждого типа. Или сделать отдельно общую таблицу с общими свойствами и отдельно по каждому типу дополнительные таблицы с полями и ссылками на основную. Как лучше?

Игорь Шевченко (2010-06-23 13:26:00) [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"

картман (2010-06-23 12:26:00) [2]

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

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

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

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

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

Строитель (2010-06-22 19:00:00) [3]
>>Anatoly Podgoretsky © (17.06.10 15:21) [1]
>>но я за одну таблицу

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

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

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

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

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

Правильный$Вася (2010-06-18 12:02:00) [4]

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

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

Anatoly Podgoretsky (2010-06-18 10:28:00) [5]
> Правильный$Вася (17.06.2010 20:01:10) [10]

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

Медвежонок Пятачок (2010-06-17 20:55:00) [6]
у этих сущностей кроме общих атрибутов типа длины цвета и запаха есть еще одно (и самое главное) общее: это всё "элементы для постройки дома"

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

Правильный$Вася (2010-06-17 20:01:00) [7]

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

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

Anatoly Podgoretsky (2010-06-17 19:35:00) [8]

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

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

Anatoly Podgoretsky (2010-06-17 19:33:00) [9]
> Sergey13 (17.06.2010 16:59:06) [6]

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

Правильный$Вася (2010-06-17 19:08:00) [10]

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

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

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

Sergey13 (2010-06-17 16:59:00) [11]
На практике, ИМХО, чаще получаются промежуточные варианты между первым (простота) и вторым (универсальность). Иногда из-за 1% сущностей неохота городить отдельные структуры, а иногда разница настолько велика, что впихивать в одну таблицу вроде и смысла то нет, кроме ИД ничего общего.

Anatoly Podgoretsky (2010-06-17 16:37:00) [12]
> Правильный$Вася (17.06.2010 15:44:03) [3]

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

Anatoly Podgoretsky (2010-06-17 16:36:00) [13]
> Правильный$Вася (17.06.2010 15:44:03) [3]

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

Правильный$Вася (2010-06-17 15:44:00) [14]

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

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

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

_REA (2010-06-17 15:29:00) [15]
Спасибо, мне тоже такое решение показалось проще.

Anatoly Podgoretsky (2010-06-17 15:21:00) [16]
> _REA (17.06.2010 14:47:00) [0]

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

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »