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

← →
_REA (2010-06-17 14:47) [0]

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

← →
Anatoly Podgoretsky © (2010-06-17 15:21) [1]

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

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

← →
_REA (2010-06-17 15:29) [2]

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

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

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

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

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

← →
Anatoly Podgoretsky © (2010-06-17 16:36) [4]

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

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

← →
Anatoly Podgoretsky © (2010-06-17 16:37) [5]

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

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

← →
Sergey13 © (2010-06-17 16:59) [6]

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

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

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

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

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

← →
Anatoly Podgoretsky © (2010-06-17 19:33) [8]

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

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

← →
Anatoly Podgoretsky © (2010-06-17 19:35) [9]

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

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

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

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

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

← →
Медвежонок Пятачок © (2010-06-17 20:55) [11]

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

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

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

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

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

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

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

← →
Строитель (2010-06-22 19:00) [14]

>>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"

Одна таблица или несколько? Найти похожие ветки