|
Rus000
Если эти термины трактовать в смысле "эпоха", то скорее всего Вы правы.
Трактуй, не трактуй - термины дореляцинная, постреляционная давно в ходу.
У СУБД есть история. Их роль все еще заметна в инфотехнологиях.
Rus000
Не сочтите за настойчивость, пожалуйста укажите ссылочку на такую статистику.
Пожалуйста
http://]http://itware.com.ua/news/9685
В интете такого полно. Не жалко.
Даже Alexey Rovdo оценивает не реляционные в 5-10%. А он представитель ООСУБД (Версант) - дает максимально оптимистическую для таковых СУБД оценку. Писсимиситечкая 1%. Ну, пусть 3-5%. Лично я могу согласиться и на 10% - ничего, мне кажется, это пока еще не меняет.
Rus000
Я - за корректность формулировок в споре :)
Ну, я не уверен, что я спорю. Просто высказываю точку зрения, защищаю ее. Но я на самом деле ни в чем не уверен на 100%. Мы обсуждаем достаточно сложную область для каких-то абсолютных истин.:)
Rus000
Источник?
Уже несколько раз писал (рука уж писать ее устала):
Томас Конноли, Каролин Бегг "Базы данных". У меня аж два издания этой книги второе и третье. Интересно, что в третьем уже меньше про иерархические.
Третьего дня купил за 700р Дейта "Введение в базы данных". Ее упоминал коллега ЧАЛ (Андрей Леонидович). Но ее даже пока не цитирую - Дейт рьяный сторонник РМД. Конноли - дает осторожные оценки. Но и они не помогают никак дореляционным СУБД.
Rus000
Рассмотрим такое технологическое новшество как сотовый телефон.
1. Супертелефон все еще телефон или уже нечто иное (коммуникатор?)?
2. Нужна ли пользователям телефона эта навязчивая функциональность? В среднем звонящие пользуются двумя-тремя-четырьмя возможностями, остальные 10 - для понтов :)
Я клоню к тому, что для того чтобы заказчика удовлетворяло приложение оно должно выполнять весь требуемый этим заказчиком функционал и неважно какая СУБД ("дореляционная","реляционная" или "постреляционная") была использована для этого. Все остальные рюшечки - от маркетологов :)
Есть разница между жизненым циклом ИС и телефоном.
Тут сравнивают еще запорожци и мерседесы.
Вот как тока заказчик поймет, что ему всучили запорожец, ему станет не все равно какая СУБД.
Тем более не все равно разработчику. Если у вас запрос - инструкция на SQL извлекает навороченную инфу - сводный отчет. Вам нужно при написании думать в основном только о том, что извлекается, а не как. Легко тестировать - оно все компактно. Вам нужно посадить десять челов едва знающих SQL - чтобы срочно налабать тучу отчетов - за приличные бабки (их подстраховывает один два опытных), Вы почуствуете разницу какая СУБД. Да там полно и других аспектов. Да и фичи имеют значение - у Вас в случае изменения требований заказчика на поздних этапах больше уверенности, что Вы выкрутитесь малой кровью - СУБД поможет.
Это в простых случаях можно налабать на клиппере, а потом нагибать на это заказчика. А по серьезному лучше иметь крепкую СУБД за спиной - на все случаи.
Rus000
Думаю каждый из нас знает массу примеров, когда приложение просто работает десятки лет и до сих пор удовлетворяет всем требованиям бизнес-процессов. И всем плевать что оно работает на коболе, паскале, мампсе, клипере, и т.д. и т.п.
Жизненый цикл нормальной ИС оценивается в 7 лет (литра таже). Десятки лет работают - знаю. Половину делают руками. 70 бухгалтеров вместо 10. Еще я знаю, что многие десятки лет обходились тока счетами - без компов.
У меня у самого есть несколько систем на Аксцессе97. Их пора снимать с экплуатации. Но они делают часть работы. Вот одна в договрной группе планового отдела. Серьезные изменеия я не могу уже делать (времени нет), а будь она на Оракле, некоторые вещи, которые они хотели было бы легко налабать. Более того, начальница планового отдела хочет, чтобы и в группе анализа была такая система, чтобы "один раз набрали и все отчеты нажатием кнопки, а не йекселе - они не могут свести концы с концами". Было бы на Оракле мож и срубил бы бабки. А Вы говорите нет разницы. И учтите еще что и сам Аксцеесс хорошо залочен для разработки одним челом. Смотря что за система. Есть разница пусть и опосредовано через разработчика. Разные усилия по разработке, по сопровожденнию. Это почуствует так или иначе заказчик.
Rus000
Ни язык, ни модель данных, ни СУБД не есть самоцель. Важен полученный результат с требуемым качеством в запланированные сроки и запланированный бюджет.
Но они есть средство существенно влияющее на эффективность системы, качество и сроки и все остальное.
Иначе бы настоящие проггеры писали бы тока на ассемблере.
Rus000
Кто это сказал, позвольте спросить?
Литра все таже, например. Но это как бы общеизвестно. РМД в общем-то изначально изобреталась в первую очередь снизить эту зависимость. По крайней мере, такое мнение встречал не раз. Кстати, мы тут на форуме из обсуждения версанта видели, что там есть настроения усилить зависмомть данных от сервера приложений. Так что это свойство РМД все еще выглядит убедительно.
Rus000
Обязательное требование декларативности к языку БД я нигде не встречал, можете указать исочник? Быть может это обязателное требование к РСУБД?
А как Вы думаете - зачем ООСУБД мучаются с декларативным OQL будучи по сути навигационными в плане доступа к данным? От того, что им делать нечего? Ясно БД - для быстрого и наиболее легкого получения инфы нужны. Вот отсюда и все растет.
Rus000
А какие еще декларативные языки Вы пожете назвать и где они применимы? Мне просто интересно
Кроме языков БД? Ну, например, генераторы отчетов, приложений, форм. Применимы в разных областях разработки приложений. Вообще им условно присовоено название языков четвертого поколения.
Rus000
Я намеренно упростил, подчеркнув аналогию с языками для ХП в РСУБД.
Вы лучше спросите у Андрея Леонидовича что представляет из себя M-технология. И что он думает про дореляционную ОМД. И где ее найти.
Узнаете много интересного.
|
