|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 20 Jul 2001 06:32:37
To : All
Subject : Re: Структура базы документов
--------------------------------------------------------------------------------
Hi !
> > > Очень хороший подход, только реализовывать надо не на РСУБД,
> >
> > Зачем ?
>
> Потому, что подобные задачи сложнее на РСУБД
> реализовываются. Можно и ОО-программированием
> на C заниматься, но некоторые этим почему-то на C++
> занимаются. Как-то оно удобнее и понятнее выходит.
:-)
Кстати, приходилось мне встречать очень объектный код от хорошего
разработчика на VBScript и, как бы это помягче, не очень объектный от не
очень хороших на ObjectPascal, например
> А главное, полученная структура СУБД и ее хранимых
> процедур, триггеров и прочего кода легко и с малыми
> изменениями наследуется в других проектах.
Это же касается и РСУБД
> > Почему ?
>
> Потому, что к ней уже неудобно SQL-ем обращаться.
Есть немного, но далеко не смертельно. Зато РСУБД очень хорошо поддержаны
разработчиками и вообще индустрией. с ними в целом проще работать на текущем
этапе
> Дальше при развитии системы будет еще хуже.
Вряд-ли, все зависит от изначальной правильности подходов, инструмент тут
вторичен
> В объектных системах это известная проблема
> - отсутствие "языка свободных запроса", подобного
> SQL. Hо на практике SQL в прикладной программе
> редко бывает нужен (часто даже вреден), т.к.
> бухгалтер SQL запросов сам писать не будет.
Это только потому, что все потребные кму запросы уже написаны разработчиком.
Которому их все равно писать
> > >Реляционная модель слаба от рождения.
> >
> > А может таки не модель, а некоторые её использующие ?
> > У меня именно так вот все и работает и на РСУБД
>
> У меня тоже работало. Пока затраты на постоянную
> модификацию структуры базы в работающей системе
> не стали превышать разумные пределы. Мне, например,
> вдруг, совершенно случайно, нужен оказался
> полнотекстовый поиск по всем вообще атрибутам
> всех объектов базы. Уже после того, как система
> поставлена заказчику и забита данными. И что мне
> делать? Полностью все таблицы перекраивать?
Hе знаю, у меня он встанет легко и тривиально (буде понадобится)
> Или изначально на всякий случай делать полную
> декомпозицию всего и вся по отдельным атрибутам, как в 1C?
Вот именно так у меня все и сделано. Правда проще, чем в 1С и, как
результат - быстрее
Hо да правда мне API, как им публиковать не надо для толп чайников
> Тогда какое отношение полученная структура будет
> иметь к реляционной?
Hикакого. Она просто будет крутиться на привычном и удобном реляционном
движке.
> > > > Как насчет пост - реляционной СУБД, типа CACHE.
> >
> > Зачем ?
>
> Однажды я был свидетелем, как на один
> завод прибежала команда разработчиков с речью: "Мы
> тут вам сейчас вашу систему усовершенствуем на основе
> современных клиент-серверных технологий и РСУБД".
> Кажется, это было в 94 г. где-то в Карелии.
> А там M-системка такая древняя стояла на основе
> терминального доступа. Когда разработчики въехали
> в постановку задачи и в ее текущую реализацию, они
> пришли к мысли, что "на РСУБД таких возможностей
> добиться нельзя, тут нужно будет очень много
> программировать вручную".
Это, по моему, там было много разработчиков и ни одного проектировщика.
> Потом им сказали, что
> первоначальный вариант системы был написан
> двумя программистами.
Ради Бога, я сам всегда считал, что чем меньше команда, тем лучше.
--
Bye ...
Тенцер А.Л.
tolik@katren.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: Rinet Corp. News Service, Novosibirsk, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
