Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 24   вперед  Ctrl
 РМД пора на пенсию?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Как известно, в настоящее время получили широкое распространение системы управления реляционными базами даннх основанные на реляционной модели данных. У большинства разработчиков программного обеспечения и системных аналитиков имеется стойкое предубеждение, что реляционная модель окончательно победила в соревновании и вытеснила с рынка другие модели представления данных. Я считаю что такая ситуация является временной и в ближайшем будущем мы все станем свидетелями ломки этого стереотипа. Системы управления базами данных сами по себе не представляют особой ценности для пользователей. Даже данные, хранящиеся в базах не представляют ценности сами по себе. Ценностью обладают законченные приложения, позволяющие пользователям моделировать некоторые аспекты своей деятельности и бизнеса с использованием вычислительной техники. Существующие в настоящее время бизнес-процессы характерезуются высокой сложностью. Наблюдается тенденция усложения бизнес процессов в связи с развитием процессов интеграции и глобализации.
Несмотря на имеющиеся достоинства, реляционная модель представления данных обладает и рядом недостатков. В случае нормализации модели предметной области БД представляет собой множество связанных друг с другом таблиц. Наряду с тривиальной необходимостью выполнять множество соединений на множестве таблиц, такая структура значительно усложняет сопровождение базы данных. При изменении бизнеса приходится заново проектировать новый вариант нормализованной базы и выкидыать труд разработчиков, затраченный на разработку предыдущей версии БД и приложений, работающих с предыдущей версией. Не спасает ситуацию и проектирование реляционной структуры таблиц, специально расчитанной на изменения модели бизнеса в процессе эксплуатации приложения. В этом случае случае, разработчики реляционных БД используют 3 подхода.
1. Динамическая модификация структуры БД приложением. Этот подход сохраняет нормализацию структуры БД. Он обладает следующими недостатками: А. невозможно провести модификацию структуры БД в пределах транзакции. При модификации структуры таблиц транзакции завершаются. В случае ошибочной модификации структуры, изменения откатить будет невозможно. Б. При изменении структуры БД изменяется структура данных введенная в БД на предыдущем этапе ее эксплуатации. В некоторых случаях законадательство или бизнес процесс требуют сохранения исторических данных в неизменном виде. В. Отсутсвие наследования в классической РМД не позволяет естественным образом моделировать наследование понятий из бизнес модели.
2. Поворот структуры БД на 90 градусов. Этот подход позволяет избавиться от недостатков предыдущего подхода. Для чистоты концепции все объекты хранящиеся в БД приходится размещать всего в нескольких таблицах. Чаще всего это две таблицы – таблица объектов, и таблица значений их аттрибутов. Это приводит к декартовому умножению колличества объектов на колличество их аттрибутов и значительному возростанию строк в таблице аттрибутов. Так же, данный подход приводит к возрастанию колличества соединений. На фоне увеличевшегося коллличества строк и разрастания размера индекса данный подход приводит к катастрофическому падению производительности БД. Дополнительным недостатками такого подхода является: - потеря информации о типе аттрибута объекта, что может привести к потере целостности данных в БД; - трудности реализации аттрибутов хранящих коллекции связей с другими объектами, находящимеся в БД (в предыдущем подходе это решается использованием связей один к одному или один ко многим, моделируемыми отдельными таблицами).
3. Использование таблиц шаблонов. В этом случае в БД создаются шаблонные таблицы с набором колонок «про запас» не сопоставленных с аттрибутами бизнес объектов. В каждой шаблонной таблице создается несколько колонок одного и того же типа, например int1, int2, int3, …, int99, float1, float2, float3, … , float99, varchar1, varchar2, varchar3, … varchar99, … Так же в БД создается модель бизнес объекта, которая описывает в какой колонке находится каждый аттрибут некоторого объекта. В этом случае одна и та же колонка шаблонной таблицы содержит значения совершенно различных аттрибутов объектов разных типов. По сравнению с ранее описанными, этот подход облегчает ситуацию, однако и он не лишен значительных недостатков. Разработчику необходимо предусмотреть все типы аттрибутов моделируемых объектов и создать «про запас» достаточное для будущего использования колличество колонок каждого потенциально полезного типа. Наряду с очевидным ограничением по колличеству аттрибутов одного типа у каждого объекта, данный подход требует построения и выполнения динамических SQL запросов. Это приводит к дополнительным затратам на реализацию и выполнение построителя динамических запросов согласно модели данных. Что опять снижает производительность и надежность этого решения.

Итак, плачевная ситуация, сложившаяся в области использования реляционных систем управления базами данных продолжает усложнятся. Мы все можем наблюдать, как производители РСУБД от отчаяния вводят в свои продукты объектные расширения (Oracle, Informix, …) и возможности по обработки XML, реализацию бизнес логики приложения на стороне СУБД средсвами процедурных языков (Oracle, Microsoft, …). По сути эта ситуация говорит о поражении реляционной модели данных как универсального средсва моделирования современных бизнес процессов.

Владельцы существующих систем управления реляционными базами данных, вложившие в разработки продуктов многие миллионы долларов, маркетологи, имеющие основной задачей рекламу продукта на рынке и просто наивные пользователи пытаются нас убедить в том, что развитие РМД эволюционным путем может сохранить инвестиции и решить все описанные проблемы. Так ли это?
26 июл 05, 18:32    [1737769]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
guest_20040621
Guest
Юноша, даже миллион диссертаций не дают Вам право писать чушь. Наведите порядок в своей голове.
26 июл 05, 18:44    [1737806]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
Давно не читал столько глупостей в одном месте одновременно.

Со времён появления коллеги ЧАЛ-а и ссылки на его бессмертное творение, думал уже ничего смешнее не увижу. Похоже ошибался.

Надеюсь это шутка или примитивный способ проверить уровень тех кто читает этот форум.
26 июл 05, 18:49    [1737823]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
XM
Member

Откуда: ненадолго из запоя
Сообщений: 1264


2 shuklin:
А слабо перевести на английский и намылить ребятам с http://www.dbdebunk.com/ ?
"One does not know whether to laugh or cry" (c)

Posted via ActualForum NNTP Server 1.2

26 июл 05, 18:59    [1737839]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Что это было? Но такие идеи

shuklin

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



shuklin

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

Так для этих законченных, а в общем случае и незаконченных приложений БД - информационных системах - СУБД представляют значимую ценность. Т.е. эти законченные или просто конченные приложения без СУБД ничего из себя могут не представлять в принципе.
А БД в частности, благодаря успехам РМД могут представлять из себя самостоятельную и значительную ценность, так как там вся инфа есть, а доступ к ней можно получить с помощью многих различных приложений.
В частности, БД могут охраняться законом. Видел в каком-то законе.
БД ядро ИС. А Вы тут придумываете исторический экскурс во времена, када БД играли роль просто данные. Из таких подходцев в инфотехнолгиях уже не вышло. Тока одна дипрессия мат обеспечения и придумывания, в частности СУБД.
26 июл 05, 19:02    [1737845]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
Vladimir Levchuk
Member

Откуда:
Сообщений: 2
Это не смешно, это провокационная попытка заставить думать. Похоже это должна была быть статья - и завязка есть ("Как известно..."), и развязка ("Так ли это?"), а вот переход "Изменение бизнеса" - "3 подхода" - "плачевная ситуация" слабоват.
Кроме того, Дима, перечисли пожалуйста объектные базы, на которых лично ты заработал деньги и назови хоть один коммерческий продукт в котором ты смог бы убедит заказчика использовать не-РБД.
26 июл 05, 19:04    [1737850]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
Sarin
Member

Откуда: Земля, Солнечная система.
Сообщений: 14485


Дело в том, что РМД, придуманная гением, делает всего одну вещь. Одну простую и банальную вещь. Она всего лишь отражает информационную картину окружающего мира. И ничего более.

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

Теперь про измену(:)) бизнесмодели. У нас на работе как-то раз квиточки на оплату сменили. Убрали одно старое поле и добавили два новых. Мы неделю их осваивали. 30 человек наделённых интеллектом и способностью мыслить.
26 июл 05, 23:26    [1738112]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
Андрей Леонидович
Guest
"Специалист" Andreww на этот (похоже единственный !) раз не ошибся. Это, действительно, в том числе, способ еще раз проверить его уровень. Все еще "два" или уже "три" можно поставить по базам данных. Но это мы определить не сможем. Ведь по существу вопросов он, предусмотрительно, никогда ничего не говорит. Наверное, чтобы не ляпнуть ненароком, как vadiminfo, "благодаря успехам РМД" !? Это он про до сих пор не формализованную и не реализованную модель данных...
27 июл 05, 01:51    [1738231]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
andy st
Member

Откуда:
Сообщений: 899
vadiminfo
Что это было? Но такие идеи
shuklin

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

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

вот сделает кто-нибудь в не представляющей никакой ценности базе из не представляющей никакой ценности таблицы запрос на не представляющие никакие ценности данные не используя какие бы то ни было заканченные приложения системы (а через QA или SQL Navigator)
select number, expired_date from credit_card where nickname = 'shuklin'
а потом заюзает эти данные для перевода пожертвования какому-нибудь благотворительному фонду...
и лишь тогда поймет человек всю глубину своих заблуждений
27 июл 05, 06:32    [1738301]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
andy st
Member

Откуда:
Сообщений: 899
Sarin
Теперь про измену(:)) бизнесмодели. У нас на работе как-то раз квиточки на оплату сменили. Убрали одно старое поле и добавили два новых. Мы неделю их осваивали. 30 человек наделённых интеллектом и способностью мыслить.

а почему Вы считаете, что софт, аналогичный используемому Вами но разработанный с использованием ОО... (или еще чего-то не реляционного)позволил бы решить бы эту задачу быстрее?
Вы считаете, что добавление двух новых свойств и удаление одного в объекта "квиток на оплату" решило бы эту проблему? и вся обвязка для вычисления значений этих свойств во всех объектах вплоть до самых предковых предков создатся автоматически и самым оптимальным образом со всех точек зрения.
и потомки примут на веру удаление свойства и сразу перестанут с ним работать или будут его сами добывать откуда-то из им только известным мест?
а пока все это будет делаться автоматически разработчик попьет чайку-кофейку...
27 июл 05, 07:09    [1738319]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
shuklin
1. Динамическая... А. невозможно провести модификацию структуры БД в пределах транзакции. При модификации структуры таблиц транзакции завершаются.

если я правильно помню, это верно не для всех СУБД (недавно где-то обсуждалось)
shuklin
Б. При изменении структуры БД изменяется структура данных введенная в БД на предыдущем этапе ее эксплуатации. В некоторых случаях законадательство или бизнес процесс требуют сохранения исторических данных в неизменном виде.
это вопще вопрос кривизны рук. Ибо "некоторые случаи" попросту требуют другой логической модели (с сущностями "историческое представление", и поэтому по прокрутовски рубить сущность в капусту под новое "историческое представление" попросту нельзяю Т.е. сушность "сущность" отличается (в этом случае) от сущности "историческое представление сущности", кхм.
shuklin
В. Отсутсвие наследования в классической РМД не позволяет естественным образом моделировать наследование понятий из бизнес модели.
ну вот в постгресе есть наследование. Но видимо именно для данных имеет смысл не только наследование (развитие логической модели в сторону версификации в потомках), но и обратная операция - "нахождение более общих предков" (доопределение иерархии в сторону обобщений, которые возможно были не важны на этапе первичной разработки модели). - по крайней мере в форуме по постгре такой вопрос _естественно_ возникал.
shuklin
2. Поворот структуры БД на 90 градусов.
... Так же, данный подход приводит к возрастанию колличества соединений. На фоне увеличевшегося коллличества строк и разрастания размера индекса данный подход приводит к катастрофическому падению производительности БД.......
тут, думается, важнее, что возникает потребность в не слишком привычном для СУБД инструментарии - сложным индексам по полям нескольких таблиц (с учетом связей). НАсколько я понимаю, в некоторых СУБД это можно решить с помощью индексов на вью. (не в теме). Но на постгре, кажется, нет.
27 июл 05, 10:55    [1738806]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
ООСУБД полезны как встроенные БД приложений, минимизирующее усилия по преобразованию данных. Если БД рассматривается как среда интеграции многих приложений, то реляционные системы предпочтительней.
Однако если реально будет внедряться SOA ( а пока что постояно выясняется, что все чего-то не хватает: обеспечили выполнение сервиса- надо каталог, есть каталоги, нужны сценарии, и т.д., ) то интеграция переносится на уровень проектирования комплекса сервисов, и опять неизбежно встает вопрос, а что значит поле X в ответе У сервиса Z? Как он соотносится с полем Q.R.P - однозначно или многозначно? Пока что наиболее адекватное средство моделирования информации - РМД. Чего там не хватает -это интеграции данных из различных неймспейсов. Таким образом, на пенсию РМД рановато - она еще послужит и в новых условиях.
27 июл 05, 10:58    [1738824]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
Sarin
Member

Откуда: Земля, Солнечная система.
Сообщений: 14485
andy st

Вопрос из серии "А на какую сумму Вы украли?". Всё дело в том, что я так не считаю. Я считаю, что если меняется в корне бизнес-модель, то поменяется и БД. Единственное, что я сказал про объектную модель, так это то, что добавление наследования в РМД - хорошая идея. Но именно добавление. И именно в РМД.
27 июл 05, 11:40    [1738993]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
XM
Member

Откуда: ненадолго из запоя
Сообщений: 1264
на правах тупой необоснованной критики дилетанта (я разобраться хочу, понять)

shuklin
Как известно, в настоящее время получили широкое распространение системы управления реляционными базами даннх основанные на реляционной модели данных.

Красивая тавтология. Где-то кавычек не хватает :)
e shuklin
У большинства разработчиков программного обеспечения и системных аналитиков имеется стойкое предубеждение, что реляционная модель окончательно победила в соревновании и вытеснила с рынка другие модели представления данных. Я считаю что такая ситуация является временной и в ближайшем будущем мы все станем свидетелями ломки этого стереотипа. Системы управления базами данных сами по себе не представляют особой ценности для пользователей. Даже данные, хранящиеся в базах не представляют ценности сами по себе. Ценностью обладают законченные приложения, позволяющие пользователям моделировать некоторые аспекты своей деятельности и бизнеса с использованием вычислительной техники. Существующие в настоящее время бизнес-процессы характерезуются высокой сложностью. Наблюдается тенденция усложения бизнес процессов в связи с развитием процессов интеграции и глобализации.
Несмотря на имеющиеся достоинства, реляционная модель представления данных обладает и рядом недостатков. В случае нормализации модели предметной области БД представляет собой множество связанных друг с другом таблиц. Наряду с тривиальной необходимостью выполнять множество соединений на множестве таблиц, такая структура значительно усложняет сопровождение базы данных. При изменении бизнеса приходится заново проектировать новый вариант нормализованной базы и выкидыать труд разработчиков, затраченный на разработку предыдущей версии БД и приложений, работающих с предыдущей версией. Не спасает ситуацию и проектирование реляционной структуры таблиц, специально расчитанной на изменения модели бизнеса в процессе эксплуатации приложения. В этом случае случае, разработчики реляционных БД используют 3 подхода.

1. Динамическая модификация структуры БД приложением. Этот подход сохраняет нормализацию структуры БД. Он обладает следующими недостатками:
А. невозможно провести модификацию структуры БД в пределах транзакции. При модификации структуры таблиц транзакции завершаются. В случае ошибочной модификации структуры, изменения откатить будет невозможно.

Гм, не совсем так, например в PostgreSQL при изменении структуры таблицы в транзакции до ее завершения блокируются запросы к этой таблице в других транзакциях.

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

Часто достаточно просто решается добавлением новых таблиц, хранящих дополнительную информацию, что позволяет предыдущим версиям приложения работать без изменений.
В. Отсутсвие наследования в классической РМД не позволяет естественным образом моделировать наследование понятий из бизнес модели.

Где можно уточнить что такое "естественный (для кого?) образ моделирования наследования понятий из бизнес модели" ?

2. Поворот структуры БД на 90 градусов.....
3. Использование таблиц шаблонов. ....

По-моему, это извращения какие-то :)
...данный подход требует построения и выполнения динамических SQL запросов. Это приводит к дополнительным затратам на реализацию и выполнение построителя динамических запросов согласно модели данных. Что опять снижает производительность и надежность этого решения.

Не факт, пока схема данных стабильна, запросы можно построить один раз и использовать многократно до следующей перестройки БД. :)

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

А что такого "плачевного" Вы видите в сложившейся ситуации? И чем все-таки вызвана "плачевность" - недостатками модели (которую, как утверждают некоторые, вообще нельзя практически реализовать) или кривизной рук (или /dev/head) разработчиков?

Мы все можем наблюдать, как производители РСУБД от отчаяния вводят в свои продукты объектные расширения (Oracle, Informix, …) и возможности по обработки XML, реализацию бизнес логики приложения на стороне СУБД средсвами процедурных языков (Oracle, Microsoft, …).

От отчаяния? Не, по-моему, XML - просто маркетинговый трюк, вызванный неворятно широким использованием XML; объектные расширения - каждый производитель понимает по-разному (у кого-нибудь есть статистика по их востребованности?)
;

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

Стоп! Когда это какая-либо модель данных была средством моделирования бизнес процессов?[/quot]


Владельцы существующих систем управления реляционными базами данных, вложившие в разработки продуктов многие миллионы долларов, маркетологи, имеющие основной задачей рекламу продукта на рынке и просто наивные пользователи пытаются нас убедить в том, что развитие РМД эволюционным путем может сохранить инвестиции и решить все описанные проблемы. Так ли это?
27 июл 05, 11:53    [1739090]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Андрей Леонидович

Все еще "два" или уже "три" можно поставить по базам данных.

И где Андрей Леонидович ставить то собирается? В своей записной книжке или на заборе? Или он уже препад в универе? Могу себе представить чему он их научит.

Андрей Леонидович

Наверное, чтобы не ляпнуть ненароком, как vadiminfo, "благодаря успехам РМД" !? Это он про до сих пор не формализованную и не реализованную модель данных...

К счастью у меня уже пять по базам данных, и министерством образования это зафиксировано. В универ к Андрей Леонидович я не пойду, вплоть до того как его лишат всех преподовательских корок.
Да и если бы не успех РМД, то БД скорее всего сильно бы зависили от приложений, написанных конкретно для нее. И потому сама по себе представляла бы меньшую ценность. Они были бы иерархическими или сетевыми. Дореляционная ОМД (ООМД без ООП???!!!), которую представляет коллега ЧАЛ, все равно бы не проканала. На нее, скорее всего, могли купиться только олухи и зеваки, не имеющие ни тока два или три, но и вообще ничего. И но бы счас доказывал крах иерархических и сетевых моделей.
27 июл 05, 20:07    [1741539]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Vladimir Levchuk
Это не смешно, это провокационная попытка заставить думать.

Спасибо за поддержку! Именно так.

Vladimir Levchuk
Похоже это должна была быть статья - и завязка есть ("Как известно..."), и развязка ("Так ли это?"), а вот переход "Изменение бизнеса" - "3 подхода" - "плачевная ситуация" слабоват.

Буду работать над продолжением ;)

Vladimir Levchuk

Кроме того, Дима, перечисли пожалуйста объектные базы, на которых лично ты заработал деньги и назови хоть один коммерческий продукт в котором ты смог бы убедит заказчика использовать не-РБД.

На данный момент на ОБД я не заработал ни бакса. Основной доход приносит как раз РБД MS-SQL. Переубедить заказчика, хм, мне пока тоже не удалось ))) А вот многие знакомые весьма успешно используют MUMPS. Мне известны несколько успешных проектов с использованием этой системы. Однако это старые проекты. Я не слышал от близких друзей и знакомых ни об одном крупном коммерческом, который бы стартовал в течении последнего года на не-РМД СУБД.
28 июл 05, 13:28    [1743583]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Sarin
Дело в том, что РМД, придуманная гением, делает всего одну вещь. Одну простую и банальную вещь. Она всего лишь отражает информационную картину окружающего мира. И ничего более.


В том то и загвостка, что рмд отражает всего лишь точку зрения одного гения на картину окружающего мира. Это маловато будет.
28 июл 05, 13:34    [1743616]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
andy st
а почему Вы считаете, что софт, аналогичный используемому Вами но разработанный с использованием ОО... (или еще чего-то не реляционного)позволил бы решить бы эту задачу быстрее?

Скажем не решить быстрее, а решить качественнее, с уменьшением совокупной стоимости владения. Причем разумеется не сама ОО модель чудом все решит. А как и в РМД разработчику придется предусмотреть все мелочи, и помедитировать над схемой классов не одни сутки. Однако, то что получится в результате будет более пригодно для сопровождения. Опять же все прекрастно понимают, что с точки зрения абстрактной матиматики для вычислительной полноты хватает всего двух логических операций и констант. Поэтому не надо говорить что на РМД можно сделать все тоже самое. Можно. И без РМД и ОМД тоже можно. Просто я считаю ОМД более удобным средством для описания моделей реального мира.
28 июл 05, 13:44    [1743700]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
4321
это вопще вопрос кривизны рук. Ибо "некоторые случаи" попросту требуют другой логической модели (с сущностями "историческое представление", и поэтому по прокрутовски рубить сущность в капусту под новое "историческое представление" попросту нельзяю Т.е. сушность "сущность" отличается (в этом случае) от сущности "историческое представление сущности", кхм.

Вот в этом то и фишка. Если эту другую модель реализовать средсвами ОМД. Затем реализовать средсвами РМД. Сравнить. То при аналогичной по представительной мощности реализации ОМД обставит РМД как по колличеству сущностей (классы вс таблицы), так по колличеству требуемых соединений, по колличеству требуемых индексов и по "интуитивной понятности".
28 июл 05, 13:49    [1743737]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Ура, ура, новый баян! Теперь сюда буду ходить радоваться. Предлагаю выдавать от мёртвого осла уши за особенные перлы. Первым сей замечательный приз получает конечно г-н shuklin за фразу
shuklin
Системы управления базами данных сами по себе не представляют особой ценности для пользователей. Даже данные, хранящиеся в базах не представляют ценности сами по себе.
Потрясающее знание жизни! Ворая пара ушей уходит Андрею Леонидовичу за (уже правда несколько устаревшее, но не менее пламенное) высказывание
Андрей Леонидович
...про до сих пор не формализованную и не реализованную модель данных...


Грустно всё это на самом деле...
28 июл 05, 14:01    [1743826]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
shuklin
Просто я считаю ОМД более удобным средством для описания моделей реального мира.
Ссылочку пожалуйста на описание ОМД. Можно неформальное.
28 июл 05, 14:04    [1743844]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
XM

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

Часто достаточно просто решается добавлением новых таблиц, хранящих дополнительную информацию, что позволяет предыдущим версиям приложения работать без изменений.


Стоп. Я говорю об изменении бизнес процесса в пределах существующих приложений. Почемуто мне везет на постановки типа.
Сделайте систему, запустите в эксплуатацию. А потом через пол года наш бизнес-процесс изменится и мы хотим перенастроить на него вашу систему
1 - не потеряв истории
2 - без перекомпиляции и привлечения программирующих разработчиков
3 - желательно чтоб перенастройку осилили наши "девочки"
и т.п.

Поэтому предусмотрите все возможные изменения уже сейчас.

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

В. Отсутсвие наследования в классической РМД не позволяет естественным образом моделировать наследование понятий из бизнес модели.

Где можно уточнить что такое "естественный (для кого?) образ моделирования наследования понятий из бизнес модели" ?

Я имел в виду: наследование сущностей бизнес модели == наследованию классов в реализации.


2. Поворот структуры БД на 90 градусов.....
3. Использование таблиц шаблонов. ....

По-моему, это извращения какие-то :)


Тем не менее их имхо используют чаще чем подход описанный в пункте 1.


Мы все можем наблюдать, как производители РСУБД от отчаяния вводят в свои продукты объектные расширения (Oracle, Informix, …) и возможности по обработки XML, реализацию бизнес логики приложения на стороне СУБД средсвами процедурных языков (Oracle, Microsoft, …).

От отчаяния? Не, по-моему, XML - просто маркетинговый трюк, вызванный неворятно широким использованием XML; объектные расширения - каждый производитель понимает по-разному (у кого-нибудь есть статистика по их востребованности?)


А с чего бы это XML такую популярность набрал? Если бы все было шоколадно в сфере РМД мы бы пользовались не деревом а несколькими CSV таблицами в одном текстовом файле, связанными через реляции.

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

Стоп! Когда это какая-либо модель данных была средством моделирования бизнес процессов?



А когда программисты занимались чем то иным чем моделированием реального мира?
28 июл 05, 14:04    [1743849]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
andy st
Member

Откуда:
Сообщений: 899
shuklin
andy st
а почему Вы считаете, что софт, аналогичный используемому Вами но разработанный с использованием ОО... (или еще чего-то не реляционного)позволил бы решить бы эту задачу быстрее?

Скажем не решить быстрее, а решить качественнее, с уменьшением совокупной стоимости владения. Причем разумеется не сама ОО модель чудом все решит. А как и в РМД разработчику придется предусмотреть все мелочи, и помедитировать над схемой классов не одни сутки. Однако, то что получится в результате будет более пригодно для сопровождения. Опять же все прекрастно понимают, что с точки зрения абстрактной матиматики для вычислительной полноты хватает всего двух логических операций и констант. Поэтому не надо говорить что на РМД можно сделать все тоже самое. Можно. И без РМД и ОМД тоже можно. Просто я считаю ОМД более удобным средством для описания моделей реального мира.

теоретики, епрст...
а что может считаться сопровождением, как не "помедитировать над схемой классов" с целью изменения функционала? и срок в "не одни сутки" совершенно не зависит от того, как была разработана система, на РМД или ОМД. Проблема только в том, насколько постановщик задачи ПОЛНО и ГЛУБОКО имел представление о проекте, чтобы предусмотреть на этапе проектирования удовлетворяющий заказчика функционал и предугадать пожелания, которые могут возникнуть на этапе сдачи проекта в пром .эксплуатацию.
а использование РМД или ОМД для реализации проекта - это уж чем лучше владеешь. и если постановщик хреново сделал свою работу, то вне зависимости от ОМД и РМД срок "не одни сутки" запросто может стать "не один месяц". и соотв, наоборот, хорошая постановка задачи делает легкой сопровождение и доработку вне зависимости от подхода...
это из личного опыта.
28 июл 05, 14:05    [1743855]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Павел Воронцов
shuklin
Просто я считаю ОМД более удобным средством для описания моделей реального мира.
Ссылочку пожалуйста на описание ОМД. Можно неформальное.


Если можно неформальное, то воспользуюсь следующей логической связкой:
Наиболее формальные модели - это те которые реализованы на языках программирования. Так как любые "формальные" языки котороыми пользуются математики далеки от тотальной формализации языков программирования. Следовательно, самым свободным от неоднозначных толкований описанием ОМД будет его реализация на одном из языков программирования. Вот моя реализация : http://www.shuklin.com/ai/ht/ru/cerebrum
28 июл 05, 14:08    [1743872]     Ответить | Цитировать Сообщить модератору
 Re: РМД пора на пенсию?  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
andy st
shuklin
andy st
а почему Вы считаете, что софт, аналогичный используемому Вами но разработанный с использованием ОО... (или еще чего-то не реляционного)позволил бы решить бы эту задачу быстрее?

Скажем не решить быстрее, а решить качественнее, с уменьшением совокупной стоимости владения. Причем разумеется не сама ОО модель чудом все решит. А как и в РМД разработчику придется предусмотреть все мелочи, и помедитировать над схемой классов не одни сутки. Однако, то что получится в результате будет более пригодно для сопровождения. Опять же все прекрастно понимают, что с точки зрения абстрактной матиматики для вычислительной полноты хватает всего двух логических операций и констант. Поэтому не надо говорить что на РМД можно сделать все тоже самое. Можно. И без РМД и ОМД тоже можно. Просто я считаю ОМД более удобным средством для описания моделей реального мира.

теоретики, епрст...
а что может считаться сопровождением, как не "помедитировать над схемой классов" с целью изменения функционала? и срок в "не одни сутки" совершенно не зависит от того, как была разработана система, на РМД или ОМД. Проблема только в том, насколько постановщик задачи ПОЛНО и ГЛУБОКО имел представление о проекте, чтобы предусмотреть на этапе проектирования удовлетворяющий заказчика функционал и предугадать пожелания, которые могут возникнуть на этапе сдачи проекта в пром .эксплуатацию.
а использование РМД или ОМД для реализации проекта - это уж чем лучше владеешь. и если постановщик хреново сделал свою работу, то вне зависимости от ОМД и РМД срок "не одни сутки" запросто может стать "не один месяц". и соотв, наоборот, хорошая постановка задачи делает легкой сопровождение и доработку вне зависимости от подхода...
это из личного опыта.


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

Тут уш медитацией над схемой классов после получения изменений ТЗ не обойдешься. Надо медитировать про запас - за ранее.
28 июл 05, 14:12    [1743916]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить