https://www.opennet.me/openforum/vsluhforumID3/60336.html Компания EnterpriseDB, выпускающая коммерческую версию свободной базы данных Postgres, объявила (http://www.reuters.com/article/pressRelease/idUS129327+27-Oct-2009+PRN20091027) о заключении партнерских отношений с мировым лидером в области Linux решений &#8211; Red Hat. Последняя намеревается инвестировать в EnterpriseDB значительные средства с целью еще глубже внедрить открытые технологии в IT инфраструктуру современных корпораций.<br><br> &#171;Совершенно очевидно, что EnterpriseDB &#8211; это ведущий разработчик Postgres для крупных предприятий. Вот почему Red Hat решил сотрудничать с этой компанией&#187; - заявил президент Red Hat Jim Whitehurst. Помимо передовых позиций в области предоставления SQL решений, EnterpriseDB имеет сходную с Red Hat модель работы с клиентами, когда необходимые услуги предоставляются в соответствии с оформленной подпиской. Это также должно способствовать сближению взглядов двух крупнейших вендоров на совместную работу.<br><br>Основное направление деятельности Ente...<br><br>URL: http://lwn.net https://www.opennet.me/openforum/vsluhforumID3/60336.html#29 Sun, 01 Nov 2009 08:47:36 GMT и много у Вас подобных стартапов? и вот это:<br>&gt;резултат нужен каждые две-три недели, огромное кол-во мертворожденных идей, крайне низкое время жизни кода, нехватка времени и денег.<br><br>так и будет продолжаться.... неужели я не понятно выразился? времени в любом случае уходит одинаково. а чаще и гораздо меньше.<br>элементарное планирование - признак более/менее серьёзной конторы.<br>&gt;dba - это вообще непозволительная роскошь.<br><br>забавно. и кто же обслуживает Ваших клиентов? кто устанавливает ОС? виртуалуи (если есть)?<br>веб-сервера? субд? патчит их наконец?<br>а ведь это нужно даже при виртуальном хостинге.....<br>&gt;вообще спор ни о чен. попросили привести в чем лажает мускуль - я привел. дальше вы пытаетесь доказать, что это вовсе не проблемы. на самом деле это очень большие проблемы.<br><br>с таким же успехом можно сказать, что Вы привели недостатки постгри и т.д.<br>(см. Вашу ссылу и обращаем внимание на dml-операции)<br>а ведь это всё вытекает потом в количество клиентов на одном серваке....<br>недостатки ddl - проблема админа. н https://www.opennet.me/openforum/vsluhforumID3/60336.html#28 Sat, 31 Oct 2009 17:45:16 GMT похоже вы не совсем понимаете темпы и условия в которых делаются веб-стартапы. резултат нужен каждые две-три недели, огромное кол-во мертворожденных идей, крайне низкое время жизни кода, нехватка времени и денег. dba - это вообще непозволительная роскошь. <br><br>вообще спор ни о чен. попросили привести в чем лажает мускуль - я привел. дальше вы пытаетесь доказать, что это вовсе не проблемы. на самом деле это очень большие проблемы.<br><br>кстати, последнее утверждение про ddl/dml только доказывает, что вы не совсем понимаете реалий веб-разработки.<br><br> https://www.opennet.me/openforum/vsluhforumID3/60336.html#27 Sat, 31 Oct 2009 14:00:10 GMT &gt;Так что это вполне нормально - добавлять поля в таблицу не проводя особо никаких расчетов (конечно, в определенных условиях). Если все это делать - уйдет слишком много времени и денег (которых скоро просто не останется, т.к. конкуренты обойдут) Именно поэтому так же существуют ORM и web-фреймворки (Django, RoR, ...)<br><br>глупости. для профи по времени делать что так, что так - один хрен.<br>к примеру (напомню, речь идёт о больших таблицах) нужно сделать некий отчёт (с введением новых полей) с приемлемым для заказчика сроком его выполнения...<br>так вот, сделать сразу правильно как правило если не проще и быстрее, то уж точно не сложнее. про мастер-детэйл - вообще без проигрышный вариант - не надо переделывать существующие приложения... по-крайней мере точно уверен, что ничего не отвалится.<br>и создание вьюх на их основе - хоть сто порций.<br>для пачки студентов, которым надо по-быстрому - да. такой подход встречал неоднократно..... но и результат их работы либо долго не живёт, либо существенно переделывается<br>по-пово https://www.opennet.me/openforum/vsluhforumID3/60336.html#26 Sat, 31 Oct 2009 12:53:45 GMT &gt; в любом случае - это не штатная ситуация. и подобные работы как правило только этим не заканчиваются. сразу же приплюсовываются расчёты на пространство, память, индексы, планы выполнения и т.д.<br><br>с таким подходом рынок интернет-сервисов еще в каменном веке бы был. сейчас решает скорость внедрения новых фич, гибкость. Так что это вполне нормально - добавлять поля в таблицу не проводя особо никаких расчетов (конечно, в определенных условиях). Если все это делать - уйдет слишком много времени и денег (которых скоро просто не останется, т.к. конкуренты обойдут) Именно поэтому так же существуют ORM и web-фреймворки (Django, RoR, ...) <br><br>Кстати, вот что-то более менее вменяемое нашел их бенчмарков mysql vs. postgres: http://www.randombugs.com/linux/mysql-postgresql-benchmarks.html<br><br>И примеры крупных интернет-проектов на постгресе по памяти: skype, myyearbook, .org, .info.<br> https://www.opennet.me/openforum/vsluhforumID3/60336.html#25 Sat, 31 Oct 2009 12:31:39 GMT ах, да.<br>&gt;алгоритмы выборки данных никто не отменял, и если майскуэль использует неверный план выполнения запроса, то время на запрос может быть на порядки выше. в вебе один 8ми секундный запрос может сильно подпортить жизнь.<br><br>и что? проектируйте б/д и пишите запросы правильно.<br>да и хинты даже в оракле никто не отменял.<br>и никаких хаков!!!:-D<br>&gt;PS: а какая у вас область деятельности, что вам не приходится менять структуру таблицы во время жизни проекта? <br><br>не скромный вопрос, но.... dba, системный архитектор, начальник ит. как-то так.<br> https://www.opennet.me/openforum/vsluhforumID3/60336.html#24 Sat, 31 Oct 2009 12:23:51 GMT &gt;проект растет и развивается =&gt; меняются задачи =&gt; меняется структура БД<br><br>в любом случае - это не штатная ситуация. и подобные работы как правило только этим не заканчиваются. сразу же приплюсовываются расчёты на пространство, память, индексы, планы выполнения и т.д.<br>как следствие - в большинстве случаев данные строки должны находится рядом, а не по всему рэйду тонким слоем... а если нет, то можно и доп. таблице подумать (master - detail). или просто построить новую (что чаще всего и происходит)<br>&gt;как минимум странный аргумент. алгоритмы выборки данных никто не отменял, и если майскуэль использует неверный план выполнения запроса, то время на запрос может быть на порядки выше. в вебе один 8ми секундный запрос может сильно подпортить жизнь.решается это как правило либо "хаками" либо прямым указанием индекса.<br><br>почему странный? никакой план выполнения не заменит здравый смысл... и факты.<br>мускуль занял место основной субд для инета по-праву. аргументы я уже приводил. не вижу смысла повторяться.<br> https://www.opennet.me/openforum/vsluhforumID3/60336.html#23 Sat, 31 Oct 2009 12:14:03 GMT &gt; а зачем её модифицировать?<br><br>проект растет и развивается =&gt; меняются задачи =&gt; меняется структура БД<br><br>&gt;&gt;Отвратительный оптимизатор запросов. Лажает в простейших ситуациях. Опять же в постгресе - большая редкость.<br>&gt;и тем не менее, запросы в мускуле выполняются быстрее. :-D не говоря уж о требуемых ресурсах.<br><br>как минимум странный аргумент. алгоритмы выборки данных никто не отменял, и если майскуэль использует неверный план выполнения запроса, то время на запрос может быть на порядки выше. в вебе один 8ми секундный запрос может сильно подпортить жизнь.решается это как правило либо "хаками" либо прямым указанием индекса.<br><br>PS: а какая у вас область деятельности, что вам не приходится менять структуру таблицы во время жизни проекта?<br> https://www.opennet.me/openforum/vsluhforumID3/60336.html#21 Sat, 31 Oct 2009 10:01:01 GMT А использовать список полей в select вместо *, чтоб обеспечить нужный порядок выборки? :)<br> https://www.opennet.me/openforum/vsluhforumID3/60336.html#19 Sat, 31 Oct 2009 02:21:47 GMT &gt;добавили бы слону нормальный partitioning и alter table add column [BEFORE,AFTER] как в мускуле и я буду самым счастливым на ЗЕМЛЕ! ;-) <br><br>а мне вот больше нужен стэндбай....<br>хотя моё личное счастье от этого не зависит.<br>