Один из активных сейчас вопросов навеял опять старую мысль

← →
Думкин © (2010-09-22 11:11) [80]

> 12 © (22.09.10 11:05) [79]

Кто на ком стоял, я не понял. Но берем обычную систему которая должна обслуживать Заказы и Закупки, со всей логистикой и платежами и уже получаем не так уж мало таблиц. Причем без фанатизма даже.

← →
Ega23 © (2010-09-22 11:13) [81]

> Кто на ком стоял, я не понял. Но берем обычную систему которая
> должна обслуживать Заказы и Закупки, со всей логистикой
> и платежами и уже получаем не так уж мало таблиц. Причем
> без фанатизма даже.

Угу.

← →
Юрий Зотов © (2010-09-22 12:14) [82]

Что сказал Том Кайт точно?

Точно он сказал вот что: если в БД более N таблиц, то с вероятностью более 90% она спроектирована неоптимально.

Это означает, что лишь 10% разработчиков способны оптимально спроектировать БД с количеством таблиц более N. С чем вполне можно согласиться.

Но Том Кайт не говорил, что не должно быть БД с количеством таблиц более N. И не надо ему этого приписывать.

← →
12 © (2010-09-22 12:24) [83]

> если в БД более N таблиц, то с вероятностью более 90% она
> спроектирована неоптимально.

да, как-то так

> Но Том Кайт не говорил, что не должно быть БД с количеством таблиц более N. И не надо ему этого приписывать

да, не говорил
нет, не надо

> Это означает, что лишь 10% разработчиков способны оптимально
> спроектировать БД с количеством таблиц более N.

необязательно означает именно это.

← →
Думкин © (2010-09-22 12:35) [84]

> 12 © (22.09.10 12:24) [83]

Замечание было не в твою сторону.

← →
vuk © (2010-09-22 12:36) [85]

Нда. У нас в базе где-то полтыщи таблиц. Это, видать, от того, что мы совсем лохи, ага.

← →
Юрий Зотов © (2010-09-22 12:37) [86]

> 12 © (22.09.10 12:24) [83]

Практически, именно это и означает. БД с 50-ю и более таблицами встречаются сплошь и рядом - и не потому, что они плохо спроектированы, а потому, что такова предметная область.

И уж кто-кто, а Том Кайт, безусловно, прекрасно это знает. Как знает и то, что разработчиков, способных спроектировать такую БД оптимально, совсем немного. О чем и сказал.

← →
Юрий Зотов © (2010-09-22 12:45) [87]

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

Замените "вид документа" на "вид товара" - получите то же самое. И т.п.

И что, Том Кайт не знает таких вещей? Трудно поверить.

← →
vuk © (2010-09-22 12:49) [88]

to Юрий Зотов © (22.09.10 12:45) [87]:

> Замените "вид документа" на "вид товара" - получите то же
> самое. И т.п.

Не, не получим. Таки товар - это сущность более простая.

← →
Ega23 © (2010-09-22 12:56) [89]

> Не, не получим. Таки товар - это сущность более простая.

Я бы не стал столь категорично утверждать, от предметной области зависит. Но в целом - согласен.

← →
Юрий Зотов © (2010-09-22 12:57) [90]

> vuk © (22.09.10 12:49) [88]

Это если не брать специфические характеристики товара (изделия). А если брать, то у холодильника они одни, а у стиральной машины - другие.

← →
12 © (2010-09-22 13:05) [91]

Убедили.
Насчет 50 - Кайт видимо предостерегал начинающих, в более метафорной форме

пол-тыщи таблиц..
и сколько записей в них?
У нас тоже есть одна - пол года там 2 записи лежат неизменными, и пол-года строчишь join всякий раз
Неужели нет таких, которые можно объединить в ущерб нормализации?

← →
Ega23 © (2010-09-22 13:06) [92]

> А если брать, то у холодильника они одни, а у стиральной
> машины - другие.

create table Goods ( GoodID int PK GoodName varchar(...), ..... ) create table GoodParams ( UID int PK, GoodID int FK на Goods, ParamValue ... ..... )

Всё от специфики зависит.

← →
Alkid © (2010-09-22 13:08) [93]

> Kerk © (19.09.10 20:15) [70]
> > Marser © (17.09.10 23:38) [61]

А кто такие эти "программисты на Дельфи" и "программисты на С#"? И какова корреляция между тем инструментом, который они сейчас используют и опытом поддержки?

← →
vuk © (2010-09-22 13:11) [94]

to Юрий Зотов © (22.09.10 12:57) [90]

> Это если не брать специфические характеристики товара (изделия).
> А если брать, то у холодильника они одни, а у стиральной
> машины - другие.

Вот ты верно заметил - специфические характеристики. Вот их и хранить отдельно. Причем, не очень долго думая, приходим к формату хранения, грубо говоря, "параметр-значение". После чего становится глубоко пофиг, параметры чего хранить.

← →
vuk © (2010-09-22 13:28) [95]

to 12 © (22.09.10 13:05) [91]:

> пол-тыщи таблиц..
> и сколько записей в них?

А где как. Где-то совсем мало, а где-то миллионы.

> Неужели нет таких, которые можно объединить в ущерб нормализации?

Я не вижу смысла смешивать сущности только ради того, чтобы устранить некоторое количество таблиц. Ведь количество таблиц - не самоцель и не главный критерий.

← →
Думкин © (2010-09-22 13:47) [96]

> 12 © (22.09.10 13:05) [91]

Есть с одной записью. И нормализации во многих нет.

← →
Alkid © (2010-09-22 15:34) [97]

> vuk © (22.09.10 13:11) [94]
> Вот ты верно заметил - специфические характеристики. Вот
> их и хранить отдельно. Причем, не очень долго думая, приходим
> к формату хранения, грубо говоря, "параметр-значение". После
> чего становится глубоко пофиг, параметры чего хранить.

Тогда возникает резонный вопрос - а зачем в таком случае использовать РСУБД?

← →
12 © (2010-09-22 15:38) [98]

> Alkid © (22.09.10 15:34) [97]

а какие есть не Р, нормальные? (скорость, документация, проверка временем, имя солидной компании за спиной, что б было понятно - завтра проект не бросят)
И главное - а что уже на таких сделано?

← →
b z (2010-09-22 15:44) [99]

> 12 © (22.09.10 15:38) [98]
Лотус, не?

← →
vuk © (2010-09-22 15:49) [100]

to Alkid © (22.09.10 15:34) [97]:

> Тогда возникает резонный вопрос - а зачем в таком случае
> использовать РСУБД?

Это надо понимать, как предложение часть реализовывать на реляционной модели, а часть - нет? И, кстати, каким боком реляционная модель здесь мешает? Вполне нормальная схема "сущность - характеристика - значение".

← →
12 © (2010-09-22 15:50) [101]

> b z (22.09.10 15:44) [99]
> > 12 © (22.09.10 15:38) [98]
> Лотус, не?

да я не знаю, я спрашиваю
наверное не так написал, как наезд - это не так :)

← →
Ega23 © (2010-09-22 15:50) [102]

> а какие есть не Р, нормальные? (скорость, документация,
> проверка временем, имя солидной компании за спиной, что
> б было понятно - завтра проект не бросят)

Caché, Postgres.

> И главное - а что уже на таких сделано?

Рамблер, например.

← →
Alkid © (2010-09-22 15:53) [103]

> 12 © (22.09.10 15:38) [98]
> а какие есть не Р, нормальные? (скорость, документация,
> проверка временем, имя солидной компании за спиной, что
> б было понятно - завтра проект не бросят)
> И главное - а что уже на таких сделано?

Ну вот, что-то нагуглил: http://en.wikipedia.org/wiki/Nosql

← →
Alkid © (2010-09-22 16:03) [104]

> vuk © (22.09.10 15:49) [100]
> Это надо понимать, как предложение часть реализовывать на
> реляционной модели, а часть - нет? И, кстати, каким боком
> реляционная модель здесь мешает? Вполне нормальная схема
> "сущность - характеристика - значение".

Нет, просто РСУБД, поддерживающая множество таблиц и ссылочную целостность становится тут overkill`ом.

← →
vuk © (2010-09-22 16:10) [105]

to Alkid © (22.09.10 16:03) [104]:

> Нет, просто РСУБД, поддерживающая множество таблиц и ссылочную
> целостность становится тут overkill`ом.

С какого перепугу-то?

← →
Игорь Шевченко © (2010-09-22 16:30) [106]

> а Том Кайт писал, что если в программе более (не помню точно
> сколько, но явно меньше 50) таблиц - то БД спроектирована
> не оптимально с вероятностью более 90%

Ты не того Кайта читал

← →
12 © (2010-09-22 16:35) [107]

> Ты не того Кайта читал

завтра напишу книгу, главу, абзац
т.к. книга дома

← →
Игорь Шевченко © (2010-09-22 16:38) [108]

vuk © (22.09.10 13:11) [94]

> Причем, не очень долго думая, приходим к формату хранения,
> грубо говоря, "параметр-значение". После чего становится
> глубоко пофиг, параметры чего хранить

Цитата (из Тома Кайта):

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

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"

> vuk © (22.09.10 16:10) [105]
> С какого перепугу-то?

С такого, что вся БД вырождается в отображение <entity, attribute> -> <value>. Если я правильно читал википедию, то это как раз идея Google Big Table, одной из нереляционных субд.

to Игорь Шевченко © (22.09.10 16:38) [108]:
Это все понятно. Но я вовсе не призывал все хранить в виде атрибутов объектов. Речь шла о конкретном применении - товары и их характеристики. Причем, как раз с учетом реляционной модели с её ссылочной целостностью, хранение информации о товарах делать в виде таблиц разной структуры под разные типы товаров как раз глупо и бессмысленно.

to Alkid © (22.09.10 16:51) [109]:

> С такого, что вся БД

Я где-то предлагал всю БД так реализовывать?

to Alkid © (22.09.10 18:01) [111]:
У нас уже лет десять так живут технические характеристики товаров:

http://www.fcenter.ru/products.shtml?eshop/act=h:a:0:7:a:a:a:0:a:1:30:r:1:1:&oper=85313::::

В данный момент это реализовано именно как хранение наборов (код_товара-имя_параметра-значение). Сейчас, правда, будем внутреннюю реализацию переделывать на более строгие связи. Если упрощенно, то будет так: (код_товара-код_характеристики-значение). Впрочем, пользователи разницы не заметят, но некоторые сервисы будет реализовать проще.

> завтра напишу книгу, главу, абзац

не, не напишу :)

все перепутал -
Это не он был, а Пол Нильсен
Не про oracle, а про mssql

в книге
http://oz.by/books/more.phtml?id=1039662&partner=booky
и сказал он как-то так

Если разработчик хвалится что создал БД с великим множеством таблиц, я чаще всего считаю что он создал провальную БД.

и приводится пример, когда он переделал БД из ~80 таблиц в БД с 17 таблицами.

А Кайт - про "неуниверсальность" писал, да, Игорь привел уже.

> и приводится пример, когда он переделал БД из ~80 таблиц
> в БД с 17 таблицами.

Можно, вообще, все в одну таблицу упихать. А смысл?

> А смысл?

разумное упрощение
там же он пишет
- все надо делать как можно проще, но не проще этого.
Чем все проще сделано - тем легче поддерживать и развивать.

там же пишет, что любит браться за проекты, обреченные с т.з. заказчика.
Типа, вытащите проект - заплачу. Нет - я уже его похоронил.
и в большинстве случаев помогает упрощение

> Не про oracle, а про mssql

И не выиграл, а проиграл (с)

> разумное упрощение

Разумную денормализацию ещё никто не отменял. Но именно разумную. Когда в жертву скорости осознанно приносится гибкость и расширяемость.

to 12 © (23.09.10 09:25) [113]:

> Если разработчик хвалится что создал БД с великим множеством
> таблиц, я чаще всего считаю что он создал провальную БД.
>

А если БД, несмотря на данное заявление, получается не провальной, то видимо провальным можно считать данное заявление. Я правильно понял? :)

> А если БД, несмотря на данное заявление, получается не провальной,
> то видимо провальным можно считать данное заявление. Я
> правильно понял? :)

не :)

> я чаще всего считаю что он создал провальную БД.

и вообще написал, т.к. грозился привести "книгу, абзац " и т.п.
а что облажался малость - ну надо и об этом сказать :)

Один из активных сейчас вопросов навеял опять старую мысль Найти похожие ветки