M>Представляете, да? При этом оператор должен видеть все эти резервации в списке, делать по ним выборку произвольным образом (а покажите-ка мне блочные резервации в отель Zurich с 15-го сентября сего года).

Ну и? В чем проблема-то?

M>Что самое интересное, в таком случае проблема не в обработке данных — что их там обрабатывать? Проблема — в самих данных. Что как и куда хранить? M>Проектировка базы — кошмар.
Почему?


M>Нормализация базы — еще тот геморрой. Расширение понятия "резервация"? Практически нереально (дополнительные таблицы, колонки, ключи...) Я конечно M>не спорю, многое зависит от кривых шаловливых ручек разработчика, но, имхо, рано или поздно приходишь к выводу, что пытаешься "впихнуть M>невпихуемое".

Может, дело не в реляционных базах — а в проектировщиках?

M>Может, ну ее, эту реляцию, к чертям? Ы?
Данивапрос. Храните во флэтфайлах — о результатах расскажите.

M>Вообще, чего мне вдруг стукнуло в голову — просто связь логики приложения и данных приложения, как таковая, отсутствует. А хоцца, чтоб не отсутствовала

Ну так наверное, надо проектировать так, что бы эта связь появилась? ORM там, паттерны всякие?

GZ>Законы теории ООП не совсем похожи на законы теории данных.
Только вот никаких законов ООП нету. Равно как и никакой строгой математики в основе.
Не более, чем удобный подход проектирования.

Здравствуйте, dmz, Вы писали:

M>>Вообще, чего мне вдруг стукнуло в голову — просто связь логики приложения и данных приложения, как таковая, отсутствует. А хоцца, чтоб не отсутствовала

dmz>Ну так наверное, надо проектировать так, что бы эта связь появилась? ORM там, паттерны всякие?

Далеко не каждое бизнес-правило можно описать при помощи средств СУБД. По крайней мере так, чтоб эту структуру данных можно было нормально использовать и изменять с минимальным перелопачиванием кода. Для этих целей существует слой бизнес-логики. Вот и получается, что бизнес-логика делается по принципу: что получится — делаем в СУБД (там и PL/SQL вспомним), что не получится — в слое бизнес-логики. ИМХО ничего хорошего в таком разделении нет.

GZ>Законы теории ООП не совсем похожи на законы теории данных.
dmz>Только вот никаких законов ООП нету. Равно как и никакой строгой математики в основе.
dmz>Не более, чем удобный подход проектирования.

Ага! На столько удобный, что стал популярен не менее чем SQL. ИМХО ООП требуется лишь время для появления хорошего языка описания ОО систем, может что-нибудь вроде низкоуровнего UML. А там может и строгую математику подведут.

M>>Представляете, да? При этом оператор должен видеть все эти резервации в списке, делать по ним выборку произвольным образом (а покажите-ка мне блочные резервации в отель Zurich с 15-го сентября сего года).

dmz>Ну и? В чем проблема-то?

Потому что блочные резервации, как резервации отдельного типа, мы храним в отдельной таблице, так? А если мне захотелось просмотреть все резервации для Zurich'a, да еще отсортированные по дате. Это уже, минимум три запроса в три таблицы с join'ами.

Ну, это еще простенько. А вот когда начинается сводка для бухгалтерии? И начинаются шаманские пляски с бубном вокруг трех типов резерваций (три таблицы), различными размерами коммисионных для разных отелей (связка двух таблиц), различные формы оплаты для отелей (связка отель-форма_оплаты-банк_if_credit_card), различные оплаты по отелям (HB/BB/Breakfast only, SNGL/DBL/TRPL/SNGL+Bosphorus View/DBL+Bosphorus View..., children(0-2,0-4,0-6,0-12...), ....). Кстати, о птичках, то есть о комнатах. Каждый отель выеживается по-своему. В The Marmara Istanbul, насколько я помню, 16 типов комнат и 4 плана для детей. В каком-нибудь мнэээ... Orsep или там Fahri — от силы 3 типа комнат (на обоих ) и дети все идут как 0-12 — бесплатно. Но дополнительную кровать в double (DBL+child) не поставят, берите triple по соответствующей цене.

Не забываем, что в зависимости от сезона цены меняются. Но не на все! Сьюты в 5-звездочных остаются по той же цене, например, а все остальное цены прыгают, куда хотят. А еще есть promotion от отелей, а еще есть даты проведения конгрессов или там Formula1, когда цены опять меняются.

А еще отели на Laleli имеют привычку менять цены, когда захотят.

А еще меняются комиссии по отелям.

А еще...

В общем, купили здесь в фирме спец. програмку для всего этого дела. 2 штуки вечнзеленых — одно рабочее место. В той программе, казалось бы, есть все — и трансферы, и гиды, и отели, и рестораны и..., и..., и... Оказалось не все. Компания согласилась дописать целый отдельный модуль, заточенный под специфику компании (гы, почти 30 мегабайтов апдейта, по-моему). Один модуль они наотрез отказались делать, говоря, что, увы, это невозможно. И, кстати, понятно, почему невозможно.

Когда нам предлагали другую программу, нам ее презентовал какой-то программер. Мы ему — а сделаешь то-то и то-то? Он пошевелил мозгами и сказал, что, мол, вы гоняете, это всю структуру базы данных менять надо.

ИМХО, насколько бы хорошо ни была спректирована база данных, расширение уже существующей системы будет проводится с большим скрипом — через введение каких-то левых таблиц, дополнительных многоэтажных запросов, дупликацию данных. И так далее. ИМХО. RDBMS хороши для заранее очерченной и четкой задачи, которая если и будет меняться, то незначительно.

Увы, лучшего пока не придумали Или придумали? *с надеждой*

M>>Что самое интересное, в таком случае проблема не в обработке данных — что их там обрабатывать? Проблема — в самих данных. Что как и куда хранить? M>Проектировка базы — кошмар.
dmz>Почему?


M>>Нормализация базы — еще тот геморрой. Расширение понятия "резервация"? Практически нереально (дополнительные таблицы, колонки, ключи...) Я конечно M>не спорю, многое зависит от кривых шаловливых ручек разработчика, но, имхо, рано или поздно приходишь к выводу, что пытаешься "впихнуть M>невпихуемое".

dmz>Может, дело не в реляционных базах — а в проектировщиках?

M>>Может, ну ее, эту реляцию, к чертям? Ы?
dmz>Данивапрос. Храните во флэтфайлах — о результатах расскажите.

Месье знает толк в извращениях

Здравствуйте, dmz, Вы писали:


GZ>>Законы теории ООП не совсем похожи на законы теории данных.
dmz>Только вот никаких законов ООП нету. Равно как и никакой строгой математики в основе.
dmz>Не более, чем удобный подход проектирования.
Более чем филосовский вопрос
И да и нет.
Сначало о математической модели. Математическая модель всегда абстрактна. Она не старается охватить сразу и все. Она просто идет по восходящей. Основная модель уточняется и уточняется. Поэтому мат. моделью ООП — может быть и машина Тьюринга. А более уточненная — модели структурного программирования. Этим насколько я помню занимался еще Дейкста. Все модели программирования были придуманы математиками. И именно Дейкстра, который был математиком, заметил что разбитие программ на более мелкие программы, значительно увеличивают понятность человеку.
Но шло время, математики нашли идеальные для себя модели. Это и функциональное программирование, и логическое, и автоматное, и событийное. Это методы программирования, которые точные модели которых легко описать. Математикам это нравилось. Но видишь ли какая штука. Не все что легко описывается математиками, легко воспринимается человеческим мозгом. И программисты как класс перестали быть математиками. Для них нужно было именно простота реализации. И будучи неподдержанными математиками они начали делать свои модели. Они начали делать не то что можно математически доказать, а то что удобно реализовать. И в результате, начали проигрывать математики. Они вырабатывали идеальные модели. Но эти идеальные мат. модели не использовались. Использовалось то, что удобно описать. Когда прочухались, было уже поздно. Они не просто пытались описать новые модели, которые были получены не ими. Они даже доказали неоптимальность такой модели. Есть такие термины как "подпорки" и "призраки". Они описаны именно математиками. А вот построить более четкую модель, того что сделано не ими, им не удалось.
Любая программа (независимо от того, функциональная или императивная) может быть описана графом. Но количество связей и их типы в программах императивных языков высокого уровня настолько велико, что однозначно ее описать если и можно, то бесполезно. Такая модель в силу ее сложности невозможно использовать.
Однако, изначально ставился вопрос, есть ли теория ООП? Да есть. Да она не покрывается полностью математикой. Да, она написана не математиками. Но она есть. И у нее есть свои законы. Просто в силу того, что математики забыли об ООП и не было крепкого фундамента, эти законы иногда трансформируются и дополняются(типа наследование как аксиома ООП). Но они есть.

С уважением, Gleb.

Здравствуйте, Mazay, Вы писали:

M>Далеко не каждое бизнес-правило можно описать при помощи средств СУБД. По крайней мере так, чтоб эту структуру данных можно было нормально использовать и изменять с минимальным перелопачиванием кода. Для этих целей существует слой бизнес-логики. Вот и получается, что бизнес-логика делается по принципу: что получится — делаем в СУБД (там и PL/SQL вспомним), что не получится — в слое бизнес-логики. ИМХО ничего хорошего в таком разделении нет.
Бизнес-правила, не все. Это так. Но если использовать их по назначению, а именно для хранения данных, то реляционная модель может описать любую предметную область. Это математически доказанный факт.(Хотя также факт что есть области где РСУБД неэффективен).

С уважением, Gleb.

Здравствуйте, Mamut, Вы писали:

M>Я думаю, многие меня поддержат. Реляционные базы данных — это большой геморрой. Возможно, ничего лучшего не придумано (?), но геморроем они от этого быть не перестают.

У меня есть большое подозрение, что ты сложность объектной модели переносишь на проблемы РСУБД.

M>Два раза мне приходилось работать над проектами (и оба раза — неудачными ), где велась работа с разнообразными, но _родственными_ объектами. Или объектами, различающимися в одном свойстве, но от этого свойства изменялась логика работы приложения.

И это конечно же были разные таблицы?

M>Пример
M>Имеем туристическую компанию, резервирующую места в отелях. Казалось бы, что может быть проще?

Действительно, пока имеем три таблицы

M>Резервации могут быть поименно/пономерно. Могут быть списком в n человек на заранее зарегистрированные номера. могут быть блоком (20 SNGL, 10 DBL, 5 TRPL) комнат на будущее.

Вырисовалась ещё одна таблица для объединения резерваций.

M>Могут быть с полным питанием (Full Board, BB), могут быть с половинным (HB).

Это всё атрибуты.

M>Могут быть с детьми (у разных отелей — разная политика на детей, например 0-6 бесплатно, 6-12 50% скидка или 0-4 бесплатно, 4-8 50%, 8-12 25%)

Это тоже атрибуты.

M>Могут попадать на межсезонье в отеле (половина — по одной цене, вторая половина — по другой, завышенной, а что делать — например Формула 1 проходит)

Это тоже атрибуты. Но пару таблиц для задания подобных расписаний добавить можно

M>Представляете, да?

Аж 6 таблиц! Ну ладно, давай округлим до 12-ти

M>При этом оператор должен видеть все эти резервации в списке, делать по ним выборку произвольным образом (а покажите-ка мне блочные резервации в отель Zurich с 15-го сентября сего года).

Проблемы юзабилити тоже уже стали проблемами реляционных БД?

M>Что самое интересное, в таком случае проблема не в обработке данных — что их там обрабатывать? Проблема — в самих данных. Что как и куда хранить? Проектировка базы — кошмар. Нормализация базы — еще тот геморрой. Расширение понятия "резервация"? Практически нереально (дополнительные таблицы, колонки, ключи...) Я конечно не спорю, многое зависит от кривых шаловливых ручек разработчика, но, имхо, рано или поздно приходишь к выводу, что пытаешься "впихнуть невпихуемое".

Да уж.

M>Может, ну ее, эту реляцию, к чертям? Ы?

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

M>Далеко не каждое бизнес-правило можно описать при помощи средств СУБД. По крайней мере так, чтоб эту структуру данных можно было нормально M>использовать и изменять с минимальным перелопачиванием кода. Для этих целей существует слой бизнес-логики. Вот и получается, что бизнес-логика M>делается по принципу: что получится — делаем в СУБД (там и PL/SQL вспомним), что не получится — в слое бизнес-логики. ИМХО ничего хорошего в таком M>разделении нет.
Ну, я согласен, что бывают проблемы — но пока большинство из них решалось. В любом случае, внятных альтернатив пока нет.

M>Ага! На столько удобный, что стал популярен не менее чем SQL. ИМХО ООП требуется лишь время для появления хорошего языка описания ОО систем, может
Это ортогональные вещи. Вы запросы как собираетесь делать без SQL? Свой язык запросов придумывать?

M>что-нибудь вроде низкоуровнего UML. А там может и строгую математику подведут.
Пока не удалось. Равно как и не удалось сделать ОО хранилища настолько же универсальными и надежными,
как SQL.

Здравствуйте, Mamut, Вы писали:

M>>>Представляете, да? При этом оператор должен видеть все эти резервации в списке, делать по ним выборку произвольным образом (а покажите-ка мне блочные резервации в отель Zurich с 15-го сентября сего года).

dmz>>Ну и? В чем проблема-то?

M>Потому что блочные резервации, как резервации отдельного типа, мы храним в отдельной таблице, так? А если мне захотелось просмотреть все резервации для Zurich'a, да еще отсортированные по дате. Это уже, минимум три запроса в три таблицы с join'ами.

Не готов я рассматривать эту задачу на уровне дизайна, потому что тут надо много думать, перед тем как что-то
предложить — слёту я такие вещи как-то не привык делать. Поэтому ограничусь тезисами:

1) при проектировании систем с большим количеством данных соображения производительности должны
превалировать над соображениями правильности — в частности, можно сознательно пойти на денормализацию

2) если вся работа с базой осуществляется через ORM layer — и никто не лазит в обход него, то урон от денормализации
может быть сведен к нулю

3) в запросе по трём таблицам с джойнами нет особых проблем, если построены индексы — так?

M>Ну, это еще простенько. А вот когда начинается сводка для бухгалтерии? И начинаются шаманские пляски с бубном вокруг трех типов резерваций (три таблицы), различными размерами коммисионных для разных отелей (связка двух таблиц), различные формы оплаты для отелей (связка

Вы сейчас рассказываете про неудобства выбранной модели, но ведь никто не сказал, что она оптимальна.

M>А еще отели на Laleli имеют привычку менять цены, когда захотят.
M>А еще меняются комиссии по отелям.
M>А еще...
Кто сказал, что есть или будет что-то, что снимет решение этих задач с проектировщика?
There isno silver bullet. Просто сложная предметная область — какой бы инструмент не выбрали, голову
поморочить придется.


M>ИМХО, насколько бы хорошо ни была спректирована база данных, расширение уже существующей системы будет проводится с большим скрипом — через M>введение каких-то левых таблиц, дополнительных многоэтажных запросов, дупликацию данных. И так далее. ИМХО. RDBMS хороши для заранее очерченной M>и четкой задачи, которая если и будет меняться, то незначительно.
Не согласен. Я полгода как не занимаюсь разработкой приложения для трейдинга — там была оракловая база таблиц на 250,
как со статическими так и динамическими данными — макс. количество строк в таблице — около 19 миллионов.
База модифицировалась практически в каждом релизе — а релизы бывали раз в неделю — раз в две недели — обычно добавлялись
новые поля, но бывало всякое. Никаких проблем с модификацией базы не было — ALTER TABLE ADD COLUMN операция почти бесплатная,
OR Layer генерировался автоматически из модели данных, скрипты для модификации базы — полуавтоматически (ессно, я их прогонял на тестовой среде)
Принципиальных проблем не было.


M>Увы, лучшего пока не придумали Или придумали? *с надеждой*
Нет.

M>>>Нормализация базы — еще тот геморрой. Расширение понятия "резервация"? Практически нереально (дополнительные таблицы, колонки, ключи...) Я конечно M>не спорю, многое зависит от кривых шаловливых ручек разработчика, но, имхо, рано или поздно приходишь к выводу, что пытаешься "впихнуть M>невпихуемое".
Ну, может не стоит так уж гнаться за нормализацией? Может быть, не рассматривать это как самоцель?

GZ>Однако, изначально ставился вопрос, есть ли теория ООП? Да есть. Да она не покрывается полностью математикой. Да, она написана не математиками. GZ>Но она есть. И у нее есть свои законы.

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

Здравствуйте, Mazay, Вы писали:
M>Ага! На столько удобный, что стал популярен не менее чем SQL. ИМХО ООП требуется лишь время для появления хорошего языка описания ОО систем, может что-нибудь вроде низкоуровнего UML. А там может и строгую математику подведут.
Ага. Только математики ещё не знают, что им предстоит.
Поздно вспомнили про математику. В школе надо было её учить, в школе.

Здравствуйте, Mamut, Вы писали:
M>>>Представляете, да? При этом оператор должен видеть все эти резервации в списке, делать по ним выборку произвольным образом (а покажите-ка мне блочные резервации в отель Zurich с 15-го сентября сего года).
dmz>>Ну и? В чем проблема-то?
M>Потому что блочные резервации, как резервации отдельного типа, мы храним в отдельной таблице, так? А если мне захотелось просмотреть все резервации для Zurich'a, да еще отсортированные по дате. Это уже, минимум три запроса в три таблицы с join'ами.
union all этих таблиц.

Здравствуйте, GlebZ, Вы писали:
GZ>Но шло время, математики нашли идеальные для себя модели. Это и функциональное программирование, и логическое, и автоматное, и событийное. Это методы программирования, которые точные модели которых легко описать. Математикам это нравилось. Но видишь ли какая штука. Не все что легко описывается математиками, легко воспринимается человеческим мозгом.
Из чего можно сделать вывод, что у математиков вместо мозгов — ...

Здравствуйте, Mamut, Вы писали:

M>Возможно, вопрос поставлен слишком жестко, но все же.

Самое забавное, но я в свое время думал именно в сторону туристического бизнеса в плане обоснования необходимости применять ООСУБД.
Собственно, то, что ты пока что рассказал, ничего сложного не представляет. Ну да, довольно таки разветвленная структура таблиц. Нудно, но не сложно. Просто сидишь и методично выписываешь все атрибуты...
Сложность — в выполнении запроса "выведи мне все предложения, удовлетворяющие вот-тому то". Ну типа "семья из двух человек с ребенком хочет отдохнуть на побережье греции". И сортировать надо по стоимости. С учетом всех этих безумных pricing rules. Даже расчет стоимости авиаперелета плохо делается автоматом. У нас так до сих пор вручную все делают. И бывают потом конфликты с авиакомпанией, когда оператор выдает билет по несуществующему тарифу.

Здравствуйте, dmz, Вы писали:


M>>Ага! На столько удобный, что стал популярен не менее чем SQL. ИМХО ООП требуется лишь время для появления хорошего языка описания ОО систем, может
dmz>Это ортогональные вещи. Вы запросы как собираетесь делать без SQL? Свой язык запросов придумывать?

Был такой язык -- Object Query Language назывался. Почил в бозе вместе с породившим его стандартом ODMG.

M>>что-нибудь вроде низкоуровнего UML. А там может и строгую математику подведут.
dmz>Пока не удалось. Равно как и не удалось сделать ОО хранилища настолько же универсальными и надежными,
dmz>как SQL.

Надежность OO хранилищи не хуже надежности SQL баз. И не выше, чем надежность железа, на котором СУБД работает

Здравствуйте, fplab, Вы писали:

F>Здравствуйте, Mamut, Вы писали:

F>Альтернативы в студию. Есть такая штука как Cache, говорят хорошая вещь.

Объектно-ориентированная, но сам движок сделан на реляционой =)
Самый большой недостаток: пока размер базы меньше размера оперативки(то бишь вся база в кэше) то все летает, но как только начинаются дисковые операции из-за того, что база разрослась, так все — "мама роди меня обратно" — начинаешь тоскливо озираться в сторону Oracle.

Здравствуйте, Ligen, Вы писали:

L>Здравствуйте, dshe, Вы писали:

D>>API Raima dbVista действительно чревато многочисленными граблями. Но это отнюдь не является следствием сетевой модели. Это скорее из-за древности данной конкретной СУБД.

L>Допустим даже это.. как насчет привести в пример какую-нибудь классную реализацию сетевой модели? )

Не приведу. Во-первых, потому что не интересовался этим вопросом, а во-вторых, должно быть такой и нет просто потому, что РСУБД значительно обогнали в своем развитии сетевые и обросли фичами, которые не присущи оригинальной реаляционной модели.

В целом, проектирование сетевой базы не отличается радикально от проектирования реляционной. И там и там определяется набор сущностей и связей между ними. Каждой сущности будет соответствовать своя таблица (record в dbVista) а связи выражаются при помощи ключей в РСУБД или set'ов в dbVista. При таком подходе, в РСУБД отношения оказываются в нормализованном виде как-то сами собой. Не знаю, пользуется ли вообще кто-то формальным подходом реляционной модели при котором берется сначала ненормализованное отношение, а потом приводится постепенно к нормальной форме необходимой степени?

Кстати, многие (если уже не все) РСУБД обладают поддержкой foreign key constraint. Это немного роднит их с сетевыми поскольку в самой идее сетевой модели изначально подразумевается валидация и контроль связей между записями.

А насчет dbVista'вского API, то его можно было обернуть в более удобоваримый вид, решающий проблемы с multithreading, type safety и прочее...

Здравствуйте, dshe, Вы писали:
D>Кстати, многие (если уже не все) РСУБД обладают поддержкой foreign key constraint. Это немного роднит их с сетевыми поскольку в самой идее сетевой модели изначально подразумевается валидация и контроль связей между записями.
Разве сетевые БД не есть РСУБД + foreign key constraint — SQL?

Здравствуйте, marat321, Вы писали:

M>Объектно-ориентированная, но сам движок сделан на реляционой =)

Разве? Там навроде движок MUMPS. А реляционка сверху прикручена.