Задачка на проектирование БД с интересным ответом

[george]

Я бы сделал просто, если только смотреть с точки зрения "красоты". Есть класс "процесс", у него два релейшеншипа один-ко-многим. Process -> user, и
Process -> user group. Баста.

С практической точки зрения триста раз подумать ...

[Vovchik]

Я бы сделал просто, если только смотреть с точки зрения "красоты". Есть класс "процесс", у него два релейшеншипа один-ко-многим. Process -> user, и
Process -> user group. Баста.

С практической точки зрения триста раз подумать ...

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

[папа Карло]

that's a bad design.

Why?

запросы попиши вокруг этого дизайна и квери план посмотри.. все встанет на свои места.

[не местный]

Товарищи, а вам не кажется, что вы валите в кучу логический и физический дизайн? Сначала обсуждаете "объекты" и "суперклассы", и тут же начинаете по ним запросы строить. Это все таки разные звери, нет?

Можно замечательно идеологически выдержанную картинку нарисовать с суперклассами и наследованием, а реализовать все это так, чтобы запросы было удобно писать и чтобы бегало быстро.

[Bege-Motek]

в аналогичной задаче применила отрицательные айди для групп и положительные для юзеров

[папа Карло]

Товарищи, а вам не кажется, что вы валите в кучу логический и физический дизайн? Сначала обсуждаете "объекты" и "суперклассы", и тут же начинаете по ним запросы строить. Это все таки разные звери, нет?

Можно замечательно идеологически выдержанную картинку нарисовать с суперклассами и наследованием, а реализовать все это так, чтобы запросы было удобно писать и чтобы бегало быстро.

разве человек про теорию спросил? меня еще никто не упрекал в путании логического и физ дизайна

[папа Карло]

в аналогичной задаче применила отрицательные айди для групп и положительные для юзеров

это совсем не правильно. почему рассказать?

[hawk]

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

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

а хотя бы потому: если в системе 10 групп на 10,000 пользователей, то поддерживание всего етого барахла, особенно если список процессов достается раз в неделю вильется в копеечку.
говоря о планах, хорошо бы знать соотношение сколько групп сколько юзеров... как часто группа может владеть процесс-ом.... а так, в общем вариантов довольно много, в общем то предложение сделать process(#process_id, user_id,group_id) + соот. constrains/indexes может вполне сработать, по крайней мере с точки зрения наименьшего копирования данных, соот. если система большей частью пишет, то может быть оптимальным.

[Bege-Motek]

это совсем не правильно. почему рассказать?

Кое-что из неправильного работает быстрее и надежнее правильного.

Вы пробовали соблюдать все 5 правил нормализации? Или 12 законов Кода? Да они в Оракле нарушены априори

Речь шла о 12000 групп и 4000000 пользователей. Да в общем-то до сих пор в SAAB бежит, правда поскромнее версия.

Хотя под конкретно эту задачу возможно и не лучший вариант. В моем случае стояла задача разветвленного контроля доступа к данным для групп и юзеров. И переход на сквозную нумерацию решил многие проблемы.

[папа Карло]

это совсем не правильно. почему рассказать?

Кое-что из неправильного работает быстрее и надежнее правильного.

Вы пробовали соблюдать все 5 правил нормализации? Или 12 законов Кода? Да они в Оракле нарушены априори

Речь шла о 12000 групп и 4000000 пользователей. Да в общем-то до сих пор в SAAB бежит, правда поскромнее версия.

Хотя под конкретно эту задачу возможно и не лучший вариант. В моем случае стояла задача разветвленного контроля доступа к данным для групп и юзеров. И переход на сквозную нумерацию решил многие проблемы.

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

ну а сквозную нумерацию можно було сделать и без отрицательных чисел... 4 млн записей совсем не показатель

[Bege-Motek]

а можно услышать как в оракле (субд) нарушены правила нормализации?

Информация в Оракле не всегда хранится в ячейках.

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

Если поле содержит null то не все операции поддерживаются

Я думаю не только Оракл не соблюдает. Что не мешает ему быть достаточно реляционным.

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

ну не совсем. Юзер и группа - объекты одного дерева. Просто юзер имеет свое расширение а группа свое.

ну а сквозную нумерацию можно було сделать и без отрицательных чисел... 4 млн записей совсем не показатель

Тут Вы правы. Хотя отработка дерева из 4000000 объектов против дерева из 200 млн документов была вполне интересной задачей. Особенно учитывая 1 гб памяти и 2 процессора Spark 400

Я девушка скромная, миллионами записей мне с Вами не меряться Это к мужу, у него там петабайты

[папа Карло]

а можно услышать как в оракле (субд) нарушены правила нормализации?

Информация в Оракле не всегда хранится в ячейках.

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

Если поле содержит null то не все операции поддерживаются

Я думаю не только Оракл не соблюдает. Что не мешает ему быть достаточно реляционным.

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

ну не совсем. Юзер и группа - объекты одного дерева. Просто юзер имеет свое расширение а группа свое.

ну а сквозную нумерацию можно було сделать и без отрицательных чисел... 4 млн записей совсем не показатель

Тут Вы правы. Хотя отработка дерева из 4000000 объектов против дерева из 200 млн документов была вполне интересной задачей. Особенно учитывая 1 гб памяти и 2 процессора Spark 400

Я девушка скромная, миллионами записей мне с Вами не меряться Это к мужу, у него там петабайты

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

[StS]

это делается элементарно....

создается убер таблица... от нее растут юзеры и группы. релейшеншипы между ИД из убер таблице в третьей таблице.

that's a bad design.

Why?

запросы попиши вокруг этого дизайна и квери план посмотри.. все встанет на свои места.

То есть, запросы к пяти таблицам (процесс, убер, узер, группа, "третья") будут проще чем к трем?

[Vovchik]

Товарищи, а вам не кажется, что вы валите в кучу логический и физический дизайн? Сначала обсуждаете "объекты" и "суперклассы", и тут же начинаете по ним запросы строить. Это все таки разные звери, нет?

Вообще при проектировании моделей данных не используются такие вещи как классы, наследования и прочее. Там есть сущности, атрибуты, ограничения и отношения. Сразу видно два подхода - программистский и аналитический. Программистский - это сверху вниз. Сначала мы сделаем дезайн софтины, там классы все такое - а потом под уже готовый дизайн софта будем думать как и где хранить данные. Результат обычно бывает плачевный бо данные не соответствуют действительности. Поскольку внешне все вроде клево - проблемы вылезают через некоторое время когда вдруг оказывается что данных которых надо - нету, а которых не надо - до фига.

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

А посему как всегда - приходится искать компромисс. Так сказать, спиралевидный процесс. Построили логическую модель. Построили физическую. Подумали над запросами и прочая. Решили что где важнее. Переделали. Подумали. И так далее... Пока не вылезет некий компромисс.

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

[Дима]

Вообще, конечно, мне было интересно, как народ укладывает иерархическую структуру классов ("сущностей" в терминах проектирования, если уж быть до конца точным) в реляционную базу данных. Мнения, в общем, разделились
Как мне кажется, в любом предложенном подходе можно найти рациональные зерна, но На компромиссы с принципами нормализации стоит ходить только в случае значительного выигрыша во времени на часто выполняемых запросах. Хранение промежуточных итогов - один из таких компромиссов в data warehouse, например.
Мне сложно себе представить запросы, в которых можно получить значительный выигрыш во времени, используя разные диапазоны ID для юзеров и групп вместо добавления одной связки. Впрочем, может быть это ограничение моей фантазии..