|
|
ru.perl- RU.PERL ---------------------------------------------------------------------- From : Artem Chuprina 2:5020/400 23 Aug 2002 16:57:19 To : "Ivan Frolcov" Subject : Re: DBI, DBD или MySQL? -------------------------------------------------------------------------------- Здравствуй, Ivan Frolcov. >> IF> А что там такого не реляционного? Графы, насколько я помню из своих >> IF> институтских еще студий, прекрасно описываются всякими матрицами IF> смежности >> IF> да матрицами инцидентности, которые прекрасно ложатся в реляционную IF> схему. IF> > Hу да. Только мы попадаем либо на рекурсивные запросы, что уже ни разу не IF> > реляционка, либо на немеряного размера базу данных (декартово произведение IF> > множества пользователей на множество объектов и на множество типов связей, IF> ибо IF> > отношения с правами там транзитивные) с ручной (посредством трехстраничной IF> Hу декартово производение никто не просит хранить физически :-) Матрица IF> инцидентности => обычное отношение многие-ко-многим + для него справочник IF> типов свзязей в виде дерева. Рекурсивный запрос. Ибо нужны потомки на всю глубину. Что ни разу не реляционка. IF> А трехстраничная процедура - тебя же не IF> удивляет перловый код более ста строк? А чем PL/SQL хуже? Да ничем. Только перловый код более ста строк у меня нигде один апдейт связи не делает по 20 минут. IF> Hе, мне правда интересно - сколько там записей в юзерах, сколько объектов и IF> сколько в справочнике типов связей? И какого рода запросы? Связей 4. Объектов и пользователей ОЧЕHЬ ПРИБЛИЗИТЕЛЬHО 2000 и 500 соответственно. Когда оракл начал дохнуть, объектов было поменьше. Да и юзеров, наверное, тоже (они тоже объекты). Hу, размер декартова произведения, насколько его удалось восстановить, я приводил. Считайте сами. >> IF> Да, но до этого все было ок. IF> > Откуда ты знаешь, когда от них ушел последний грамотный админ? IF> Я знаю, что у них тогда оборот был сильно меньше :-) Hу и потом тоже стал IF> меньше :-) Я не про то. Я про то, с какого перепугу _ты_ обвиняешь в их проблемах MySQL. _Они_ могут валить вину на что угодно. А проблемы, скорее всего, с библиотекой rookie.so. О чем говорит в том числе и выбор СУБД без средств referential integrity и транзакций. В своей нише MySQL вполне себе работает, в отличие от оракла, который в этой нише отдыхает. И уж тем более тут совершенно ни при чем PostgreSQL, у которого совершенно другая ниша. И который в ней тоже почему-то работает. В отличие от Oracle, который в этой нише еще как-то работает, а в этом окружении - уже слишком как-то. А на родных средствах ездить, во-первых, непереносимо на альтернативный storage (а неадекватность реляционного таки имеет место быть), во-вторых, дорого для клиента, в-третьих, дорого в разработке. -- Artem Chuprina Communiware.net RFC2822: <ran@ran.pp.ru>, FIDO: 2:5020/358.49, ICQ: 13038757 --- ifmail v.2.15dev5 * Origin: Leninsky 45 home network (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.perl/14454f4b36834.html, оценка из 5, голосов 10
|