https://m.opennet.dev/openforum/vsluhforumID3/78812.html Майкл Стоунбрейкер (Michael Stonebraker (http://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%BE%D1%83%D0%BD%D0%B1%D1%80%D0%B5%D0%B9%D0%BA%D0%B5%D1%80,_%D0%9C%D0%B0%D0%B9%D0%BA%D0%BB)), один из основоположников теории баз данных, принимавший участие в разработке архитектуры СУБД как Ingres, Informix, PostgreSQL, SciDB (http://www.opennet.ru/opennews/art.shtml?num=30983) и VoltDB (http://www.opennet.ru/opennews/art.shtml?num=26732), рассуждая (http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-than-death/) о масштабировании СУБД, упомянул, что поддержание огромной и сложной реализацией MySQL в Facebook "хуже чем смерть" и есть только один выход из сложившейся проблемы - сделать невозможное и переписать весь код. Это проблема касается и многих других web компаний, которые начинают с малого, а затем увеличиваются до огромных размеров.<br><br><br>В настоящее время, чтобы справится с нагрузкой, которую создают 750 миллионов пользователей, Facebook оперирует четырьмя тысячами экземпляров (исполь...<br><br>URL: http://gigaom. https://m.opennet.dev/openforum/vsluhforumID3/78812.html#92 Wed, 26 Sep 2012 15:11:36 GMT блять, ну почему базы сразу в Jdb было не сделать??<br> https://m.opennet.dev/openforum/vsluhforumID3/78812.html#91 Mon, 19 Dec 2011 11:47:27 GMT Автор этой статьи АБСОЛЮТНО не понимает о чем пишет. И ни один(!) комментатор не понял этого.<br><br>Этот тупица взял отличную статью от GigaOM и приписал туда несуществуюший _проект_ NewSQL. Несуществующий проект затем был привязан к _проекту синтаксиса_ мертвого с 2003го (!) года на sourceforge.<br><br>VoltDB кстати работает отлично.<br> https://m.opennet.dev/openforum/vsluhforumID3/78812.html#90 Wed, 13 Jul 2011 08:56:16 GMT Да ну неужели ? <br> https://m.opennet.dev/openforum/vsluhforumID3/78812.html#89 Wed, 13 Jul 2011 04:11:21 GMT &gt; Каков бы ни был оптимизатор, <br>&gt; человек лучше знает СЕМАНТИКУ данных, т.е. его запросы будут априори лучше. <br><br>Увы, это часто совсем не так. Человек не знает, да и не может знать, статистик таблиц БД. <br><br>&gt; Да и сам SQL довольно неуклюж для нетривиальных задач - он <br>&gt; оперирует множествами, а это не всегда удобно. https://m.opennet.dev/openforum/vsluhforumID3/78812.html#88 Wed, 13 Jul 2011 04:08:31 GMT &gt;&gt; В любом случае, ни Postgres, ни MSSQL, ни Oracle, ни MySQL <br>&gt;&gt; не понимают, что можно сделать одну выборку, а не две.<br>&gt; http://www.postgresql.org/docs/9.0/static/queries-with.html <br><br>Знаю. Но при построении отчета дополнительные условия WHERE я могу наложить только на последний SELECT. Из-за этого вложенные гребут все не фильтруя - прощай оптимизация.<br><br> https://m.opennet.dev/openforum/vsluhforumID3/78812.html#87 Wed, 13 Jul 2011 04:06:44 GMT &gt; Неправда. В Pg, Оракл и некоторых других СУБД есть оконные функции, часть <br>&gt; подобных задач с их помощью решать можно.<br><br>Вот и подтверждение моему утверждению. Проблема известна, некоторые разработчики БД придумывают расширения для SQL, пытаясь решить проблему. Хотя более правильным, была бы разработка либо нового стандарта SQL(что хуже), либо нового языка запросов к БД.<br> https://m.opennet.dev/openforum/vsluhforumID3/78812.html#86 Tue, 12 Jul 2011 10:20:06 GMT &gt; вы с этим к 1с сходите.<br><br>В 1с код пишется на языке 1с, а не на голом SQL-е, так что мимо кассы.<br> https://m.opennet.dev/openforum/vsluhforumID3/78812.html#85 Tue, 12 Jul 2011 06:02:20 GMT Мне тоже нравится подход, когда любой запрос (даже если движок имеет другой фронт) транслируется в SQL, который предоставляется мне для ревизии.<br> https://m.opennet.dev/openforum/vsluhforumID3/78812.html#84 Tue, 12 Jul 2011 05:06:50 GMT &gt; Такие портянки в приличных местах не показывают.<br>&gt; Одни только магические константы чего стоят.<br><br>вы с этим к 1с сходите.<br>