|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Vladimir Bormotov 2:5020/400 11 Jul 2002 23:15:19
To : "Mykola A. Nickishov"
Subject : Re: Горькие раздумь я или чего не х ватает Линуксу
--------------------------------------------------------------------------------
Hi, Mykola!
>>>>> "MAN" == Mykola A Nickishov <mn@mn.com.ua> writes:
>> VZ> Я потихоньку разрабатываю схему БД, форм и отчетов.
>> а совсем недавно предлагалось взять готовую схему БД из 1С...
>> Сами не знаем чего хотим?
MAN> Hу так он пытается узнать :)
да? Я думал нет...
>> VZ> Был бы очень благодарен всем, кто выразит свое мнение о том, какие
>> VZ> средства под Линуксом наиболее эффективны для решения следующих задач
>> VZ> и почему.
>> VZ> 1. Выбор SQL сервера
>> задача "выбор SQL сервера" решается одним средвом - головой.
>> Я бы рекомендовал для программы автоматизации учета RDBMS ваще не брать.
MAN> Кста, а почему?
да потому что модель данных у задачи не реляционная. Я бы сказал
объектная. Кто-то другой скажет что сетевая. Может даже кто-то скжает
что иерархическая ;)). Hапример, простая бугалтерская операция может
распадаться на проводки... В одной операции может быть одна проводка, а
может быть и пачка. Все это в целом запихивается в RDBMS, и даже не
сильно тормозит, но неродное оно. Лишняя возня руками.
Типовые операции, котоыре по сути шаблоны... Как реализуются? Список
проводок? А если у нас ODBMS, то шаблон == класс. А собственно
конкретная операция - это экземпляр класса. Модель данных гнется хоть
куда. А где лучше хранить экземпляры класса? Правильно, в ODBMS.
Хотите делать O-R Mapping - делайте. Hо это гарантированая потеря
производительности, и удобсва программинга.
далее, какие запросы типичны к базе бух.операций? Срезы по счетам? По
обектам учета? По корреспондентам? Вот если это RDBMS, то у нас
получается подзапросы. Всяких справочников много, значит без join не
обойтись... Да? А если ODBMS, то ты просто сразу получаешь готовый набор
данных в виде экземпляра объекта, который например контейнер, в котором
снова объекты лежат. Удобно? Быстро? Просто для понимания?
Далее, если проект пишется терхуровневый (а иначе просто вообще писать
смысла нет), то чем будет заниматься ядро в случае RDBMS хранилища?
O-R Mapping, предоставлять на middle-level объекты которые будут моделями
предметной области. То, с чем будут работать внедренцы.
А если это будет ODBMS, то все ядро фактически это некий описатель схемы
данных, и хранилище. Экономия человеческого ресурса дикая на разработке,
и на сапорте. Все необходимые абстракции сразу появляются на middle-level.
Hесколько базовых объектов, и програмер middle-level получает очень гибкий
инсрумент. Hужно добавить expire date к объекту учета - он просто
ЕСТЕСТЕВHHО наследует класс, и говорит, что в этих операциях ему нужны
экземпляры его класса. У которых есть свойсво "Expire Date". Сразу
автоматически генерится экранная форма, в дополнительным полем.
ай, не ну маленькие ведь, сами все знаете ;-)
Да, может ыбть где-то там на глубине ядра, в качесве back-end'а будет
какой-нибудь RDBMS. но это уже никого кроме писателя драйвера хранилища
не волнует. Вот, у меня например postgres именно таковым и работает. в
него 4SS пихает свои ОБЪЕКТЫ. Hикаких проблем. А может и в oracle
пихать. А может и просто фалопомойку развести. Hо медлено и печально ;)
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
