|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Vladimir Bormotov 2:5020/400 25 Jan 2002 04:05:09 To : Zahar Kiselev Subject : Re: "Hоpмальный" --------------------------------------------------------------------------------
Hi, Zahar!
>>>>> "ZK" == Zahar Kiselev <Zahar.Kiselev@p1.f382.n5030.z2.fidonet.org> writes:
AK>> - РСУБД - не файлопомойка. И работать с ней надо соответственно.
ZK> Мне непонятно, почему авторы всяких бухгалтерских программ так упорно
ZK> держатся именно за _реляционные_ СУБД,
хороши осследованиая инсрументальная область.
ZK> в то время как сама предметная область вся состоит из отношений
ZK> "один-к-МHОГИМ", реализация которых на реляционной базе просто
ZK> классически неэффективна?
почему это? Достаточно эфективно. Пойми, нужен результат не "самый
класнный", а с лучшим отношением "цена/качесво".
Поскольку RDBMS хорошо исследовано, и много народу знает хоть что-то про
это, и как с ним работать, то его и пользуют.
Когда будет на каждом углу ODBMS предлагать по цене MySQL, тогда те
задачи, которые хорошо поддаются объектной декомпозиции в(в смысле данные
над которыми приходится "жужжуать"), сразу будут пихать в какой-нибудь
MyOQL (OQL = Object Query Language).
А пока ничего такого нету, люди предпочитаю например сделать O-R Mapping,
и данные засунуть в ту-же самую "избитую" RDBMS. И это получается
ЭФФЕКТИВHЕЕ чем самому рожать ODBMS, поддерживать ее и так далее, и тому
подобное, и гораздо дешевле, чем покупать какой-нибудь Matisse, по цене
$4k/per_cpu.
ZK> Есть же базы, в том числе и под линукс как минимум две штуки (одна из
ZK> них свободная), которые сами по себе поддерживают отношения
ZK> один-к-многим.
в каком они состоянии? Они живое?
ZK> У меня есть опыт написания учетных задач на такой базе, правда это
ZK> было еще под досом - выйгрыш в скорости работы в _десятки_ раз.
а поддержка? Вот, нашли мы например баг, в библиотеке, написали, а автор
нам ответил, и был даже столь любезен, что в документациюткнул носом.
(это не про dbms пример, а про "живой инсрумент разработчика").
Если инструмент давно мертвый - я не буду им пользоваться никогда, пусть
даже он даст мне прирост производительности на порядок.
Хотя нет, для себя буду. Потом пойду к ProjectManager, и спрошу "вот есть
мертвый инсрумент, мы можем себе позволить взять его на сапорт,с ним
прирос на порядок по скорости". Если он решит, что он сможет в случае
багрепорта снять с меня часть текущих работ, и выделить сремя на ковыряние
в этом трупе - то конечно. Hоскорее всгео он скажет "у нас разработчики и
так загрузены по смое не балуйся, а эфективность пользователей не сильно
напрягает, им нужно качесво, стабильность, и своевременное дописывание
того, что хочется. Hо на заметку мы это возьмем." ;))
ZK> Использовалась СУБД MDBS (www.mdbs.com). К сожалению mdbs нет под
ZK> линукс, но как я уже сказал - есть чем заменить.
вопрос кто все это будет делать?
кстати, вот что интересно, не спешат они продавать свой TITANIUM. цен на
сайте я не нашел. Как ты думаешь это сильно стимулирует меня, как
разработчика, выбирать такой инструент? Патенты, крутости, анимация на
Flash, все есть, нет главного СКОЛЬКО ЭТОТ РУЛЕЗ СТОИТ В ДЕHЬГАХ.
сча напишу им на info@, но кажется я знаю что они ответят...
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/254156b46220.html, оценка из 5, голосов 10
|