Страница 2 из 3
Добавлено: 13 дек 2006, 15:29
george
Я бы сделал просто, если только смотреть с точки зрения "красоты". Есть класс "процесс", у него два релейшеншипа один-ко-многим. Process -> user, и
Process -> user group. Баста.
С практической точки зрения триста раз подумать ...
Добавлено: 13 дек 2006, 15:35
Vovchik
george писал(а):Я бы сделал просто, если только смотреть с точки зрения "красоты". Есть класс "процесс", у него два релейшеншипа один-ко-многим. Process -> user, и
Process -> user group. Баста.
С практической точки зрения триста раз подумать ...
Тыда могешь обойтись тремя таблицами - юзер, группа, процесс. А ежели у всех трех сущностей отношения - многие ко многим? Тыда пересечения надо хранить в четвертой таблице.
Добавлено: 13 дек 2006, 16:16
папа Карло
StS писал(а):папа Карло писал(а):
that's a bad design.
Why?
запросы попиши вокруг этого дизайна и квери план посмотри.. все встанет на свои места.
Добавлено: 13 дек 2006, 17:25
не местный
Товарищи, а вам не кажется, что вы валите в кучу логический и физический дизайн? Сначала обсуждаете "объекты" и "суперклассы", и тут же начинаете по ним запросы строить. Это все таки разные звери, нет?
Можно замечательно идеологически выдержанную картинку нарисовать с суперклассами и наследованием, а реализовать все это так, чтобы запросы было удобно писать и чтобы бегало быстро.
Добавлено: 13 дек 2006, 19:09
Bege-Motek
в аналогичной задаче применила отрицательные айди для групп и положительные для юзеров
Добавлено: 13 дек 2006, 20:09
папа Карло
не местный писал(а):Товарищи, а вам не кажется, что вы валите в кучу логический и физический дизайн? Сначала обсуждаете "объекты" и "суперклассы", и тут же начинаете по ним запросы строить. Это все таки разные звери, нет?
Можно замечательно идеологически выдержанную картинку нарисовать с суперклассами и наследованием, а реализовать все это так, чтобы запросы было удобно писать и чтобы бегало быстро.
разве человек про теорию спросил? меня еще никто не упрекал в путании логического и физ дизайна
Добавлено: 13 дек 2006, 20:10
папа Карло
Bege-Motek писал(а):в аналогичной задаче применила отрицательные айди для групп и положительные для юзеров
это совсем не правильно. почему рассказать?
Добавлено: 13 дек 2006, 21:37
hawk
папа Карло писал(а):Marmot писал(а):А я бы сделал так что бы владеть процессом могли только группы.
Не вижу ничего неправильного в том что в группе может быть один юзер.
Зато всё будет логично и прямолинейно...
управление через группы логичнее, абсолютно согласен, анлесс есть какие либо интересные требования почему так не может ьыть сделано.
а хотя бы потому: если в системе 10 групп на 10,000 пользователей, то поддерживание всего етого барахла, особенно если список процессов достается раз в неделю вильется в копеечку.
говоря о планах, хорошо бы знать соотношение сколько групп сколько юзеров... как часто группа может владеть процесс-ом.... а так, в общем вариантов довольно много, в общем то предложение сделать process(#process_id, user_id,group_id) + соот. constrains/indexes может вполне сработать, по крайней мере с точки зрения наименьшего копирования данных, соот. если система большей частью пишет, то может быть оптимальным.
Добавлено: 13 дек 2006, 21:55
Bege-Motek
папа Карло писал(а):это совсем не правильно. почему рассказать?
Кое-что из неправильного работает быстрее и надежнее правильного.
Вы пробовали соблюдать все 5 правил нормализации? Или 12 законов Кода? Да они в Оракле нарушены априори
Речь шла о 12000 групп и 4000000 пользователей. Да в общем-то до сих пор в SAAB бежит, правда поскромнее версия.
Хотя под конкретно эту задачу возможно и не лучший вариант. В моем случае стояла задача разветвленного контроля доступа к данным для групп и юзеров. И переход на сквозную нумерацию решил многие проблемы.
Добавлено: 13 дек 2006, 22:09
папа Карло
Bege-Motek писал(а):папа Карло писал(а):это совсем не правильно. почему рассказать?
Кое-что из неправильного работает быстрее и надежнее правильного.
Вы пробовали соблюдать все 5 правил нормализации? Или 12 законов Кода? Да они в Оракле нарушены априори
Речь шла о 12000 групп и 4000000 пользователей. Да в общем-то до сих пор в SAAB бежит, правда поскромнее версия.
Хотя под конкретно эту задачу возможно и не лучший вариант. В моем случае стояла задача разветвленного контроля доступа к данным для групп и юзеров. И переход на сквозную нумерацию решил многие проблемы.
а можно услышать как в оракле (субд) нарушены правила нормализации? то решение что у вас там сделано нарушает первую нормальную форму... вопрос если вам не надо первую нормальную форму, то зачем использовать реляционный двигатель?
ну а сквозную нумерацию можно було сделать и без отрицательных чисел... 4 млн записей совсем не показатель
Добавлено: 13 дек 2006, 22:29
Bege-Motek
папа Карло писал(а):а можно услышать как в оракле (субд) нарушены правила нормализации?
Информация в Оракле не всегда хранится в ячейках.
Оракл не всегда может обеспечить доступ к сохраненным данным через простой запрос
Если поле содержит null то не все операции поддерживаются
Я думаю не только Оракл не соблюдает. Что не мешает ему быть достаточно реляционным.
папа Карло писал(а):
то решение что у вас там сделано нарушает первую нормальную форму... вопрос если вам не надо первую нормальную форму, то зачем использовать реляционный двигатель?
ну не совсем. Юзер и группа - объекты одного дерева. Просто юзер имеет свое расширение а группа свое.
папа Карло писал(а):
ну а сквозную нумерацию можно було сделать и без отрицательных чисел... 4 млн записей совсем не показатель
Тут Вы правы. Хотя отработка дерева из 4000000 объектов против дерева из 200 млн документов была вполне интересной задачей. Особенно учитывая 1 гб памяти и 2 процессора Spark 400
Я девушка скромная, миллионами записей мне с Вами не меряться
Это к мужу, у него там петабайты
Добавлено: 13 дек 2006, 22:33
папа Карло
Bege-Motek писал(а):папа Карло писал(а):а можно услышать как в оракле (субд) нарушены правила нормализации?
Информация в Оракле не всегда хранится в ячейках.
Оракл не всегда может обеспечить доступ к сохраненным данным через простой запрос
Если поле содержит null то не все операции поддерживаются
Я думаю не только Оракл не соблюдает. Что не мешает ему быть достаточно реляционным.
папа Карло писал(а):
то решение что у вас там сделано нарушает первую нормальную форму... вопрос если вам не надо первую нормальную форму, то зачем использовать реляционный двигатель?
ну не совсем. Юзер и группа - объекты одного дерева. Просто юзер имеет свое расширение а группа свое.
папа Карло писал(а):
ну а сквозную нумерацию можно було сделать и без отрицательных чисел... 4 млн записей совсем не показатель
Тут Вы правы. Хотя отработка дерева из 4000000 объектов против дерева из 200 млн документов была вполне интересной задачей. Особенно учитывая 1 гб памяти и 2 процессора Spark 400
Я девушка скромная, миллионами записей мне с Вами не меряться
Это к мужу, у него там петабайты
то, что не все операции поддерживаются... так для релационности все что надо это стандартные операции по работе со множествами... они в оракле точно есть. и null тут будет не при чем.
то, что не всегда значение хранится в ячейках, так "невсегда" здесь будет являться ключевым словом.
храниться будет так, как вы скажете...
Добавлено: 14 дек 2006, 07:54
StS
папа Карло писал(а):это делается элементарно....
создается убер таблица... от нее растут юзеры и группы. релейшеншипы между ИД из убер таблице в третьей таблице.
папа Карло писал(а):StS писал(а):папа Карло писал(а):
that's a bad design.
Why?
запросы попиши вокруг этого дизайна и квери план посмотри.. все встанет на свои места.
То есть, запросы к пяти таблицам (процесс, убер, узер, группа, "третья") будут проще чем к трем?
Добавлено: 14 дек 2006, 09:05
Vovchik
не местный писал(а):Товарищи, а вам не кажется, что вы валите в кучу логический и физический дизайн? Сначала обсуждаете "объекты" и "суперклассы", и тут же начинаете по ним запросы строить. Это все таки разные звери, нет?
Вообще при проектировании моделей данных не используются такие вещи как классы, наследования и прочее. Там есть сущности, атрибуты, ограничения и отношения. Сразу видно два подхода - программистский и аналитический. Программистский - это сверху вниз. Сначала мы сделаем дезайн софтины, там классы все такое - а потом под уже готовый дизайн софта будем думать как и где хранить данные. Результат обычно бывает плачевный бо данные не соответствуют действительности. Поскольку внешне все вроде клево - проблемы вылезают через некоторое время когда вдруг оказывается что данных которых надо - нету, а которых не надо - до фига.
Аналитический. Снизу вверх. Сначала делаем модель данных. Которая отражает бизнес модель. Сущности, атрибуты, отношения. Поток данных. Потом логическую модель проецируем в физическую. Потом строим над схемой данных приложение. Результат - лучше чем в первом случае но да писание запросов может вылиться в то еще упражнение.
А посему как всегда - приходится искать компромисс. Так сказать, спиралевидный процесс. Построили логическую модель. Построили физическую. Подумали над запросами и прочая. Решили что где важнее. Переделали. Подумали. И так далее... Пока не вылезет некий компромисс.
Однако лично я сторонник аналитического дезайна. Снизу вверх. Бо бизнес процесс и модель данных - это значительно более стабильные вещи чем желание юзверей придумать еще какие нить отчеты. Опять же переписать че нить там в софте - это одно. А переделвать модель данных - это все, туши свет.
Добавлено: 14 дек 2006, 09:44
Дима
Вообще, конечно, мне было интересно, как народ укладывает иерархическую структуру классов ("сущностей" в терминах проектирования, если уж быть до конца точным) в реляционную базу данных. Мнения, в общем, разделились
Как мне кажется, в любом предложенном подходе можно найти рациональные зерна, но
На компромиссы с принципами нормализации стоит ходить только в случае значительного выигрыша во времени на часто выполняемых запросах. Хранение промежуточных итогов - один из таких компромиссов в data warehouse, например.
Мне сложно себе представить запросы, в которых можно получить значительный выигрыш во времени, используя разные диапазоны ID для юзеров и групп вместо добавления одной связки. Впрочем, может быть это ограничение моей фантазии..