Вышли обновления всех активных версий Postgre SQL

>А в Postgre появился FULLTEXT?

Может, имеет смысл проснуться и оглядеться? Вообще, уже 2006 год на дворе А вы все до сих пор во времена рождения 3 ветки мыскля живете

Да и стыдно так по-детски лажаться

Еще раз повторю - мысклевский полнотекст рядом не валялся с tsearch2

> sqlite потянет на средней машине 1000 конкуррирующих запросов в секунду, из которых 60% SELECT и 40% UPDATE?

Вопрос некорректен 1) Что за запросы? Некоторые запросы на "средней" машине и мыскль не потянет 2) С каким мысклем сравниваем? Надеюсь, с 3 веткой? sqlite на большее не претендует

P.S. Вылезли пофлеймить с детьми?

> То, что любая ошибка в AS будет НЕИСПРАВИМА и данные придут в СУБД неконсистентными.

Опять незачёт. Ровно тоже самое можно сказать и внутренних механизмах
контроля в любой СУБД. Если они дадут сбой, данные потеряют целостность.
Ваше обоснование - туфта и детский лепет.

> Короче, граждане спорщики! Сначала прочитайте про то, что Постгрес умеет

Возможно. Давно не интересовался вопросом. Но помню, что когда в mysql
эта фича появилась, в постгресе её в помине не было.

> Вообще, уже 2006 год на дворе А вы все до сих пор во времена рождения 3 ветки мыскля живете

Мне это говорит лишь о том, что в "мыскле" эти фички появились ну очень
давно и работали штатно из коробки, а в постгресе они стали появляться
заметно позже, и по началу были в виде разнокалиберных довесков,
сработанных топором и напильником. Нечем гордиться, короче.

> Еще раз повторю - мысклевский полнотекст рядом не валялся с tsearch2

Правда? А что он может?

>Мне это говорит лишь о том, что в "мыскле" эти фички появились ну очень >давно и работали штатно из коробки, а в постгресе они стали появляться >заметно позже, и по началу были в виде разнокалиберных довесков, >сработанных топором и напильником. Нечем гордиться, короче.

Не покажете, с какой скоростью все из коробки работало хотя бы на 10,000 уникальных лексеммах и 100,000 документах?

Не подскажете, как там обстоят дела с морфологией? Ее нет или она есть? Она есть или ее нет?

Свои словари подключать можно? Список стоп-слов определять можно?

Дальше продолжать, пожалуй, смысла нет. Мысклевский полнотекст как был в зачаточном состоянии, так и остался. Фигня, но зато из коробки пятилетней давности.

>Опять незачёт. Ровно тоже самое можно сказать и внутренних механизмах контроля в любой СУБД. Если они дадут сбой, данные потеряют целостность. Ваше обоснование - туфта и детский лепет.

Еще раз и мееееедленно. В отсутствие AS, СУБД без контроля ссылочной целостности - просто набор несвязанных данных. Каша. Помойка.

Поскольку во всех мало-мальски серьезных проектах доступ к СУБД ведется разными клиентами (в общем смысле этого слова), при отсутствии внутреннего контроля ссылочной целостности базы и непротитиворечивости данных для нормальной работы придется писать слой абстракции и осуществлять доступ только серез него.

В серьезных проектах этот слой абстракции будет ОЧЕНЬ сложным. И при изменении бизнес-логики системы придется переписывать именно этот слой, что означает нестабильность всего проекта в целом. Писать 10000 загружаемых .so c разделением элементов бизнес-логики не предлагать - так никто не делает и примеров такого нет (если есть, покажите).

Поясняю для самых маленьких: Например, есть у нас некая система платежей, понадобилось каким-то образом рассчитывать бонусы за определенное количество покупок. Если бизнес-логика в системе зашита в AS, придется переписывать код самого AS, всех вспомогательных сервисов и т.д. Если у нас есть возможность хранить бизнес-логику в самой базе, нужно только создать необходимый триггер и все.

Писать триггеры ПРОЩЕ чем переписывать уровень абстракции СУБД. Хотя бы потому что меняется меньше кода, и следовательно новую систему проще тестировать и отлаживать.

>Возможно. Давно не интересовался вопросом. Но помню, что когда в mysql эта фича появилась, в постгресе её в помине не было.

Какая конкретно фича?

На самом деле совершено неважно что и у кого появилось раньше. Важно то как дела обстоят сейчас. Так вот, в данный момент MySQL предлагает меньшую функциональность чем PostgreSQL. Увы. Возможно, когда пятая ветка станет rock-stable, MySQL и будет конкурентом PostgreSQL 7.X. Но пока этого нет.

господа мускулисты, скажите пожалуйста когда в mysql появится нормальный клиент из коробки для работы с этой СУБД. Про извечный прикол автодополнения insert insert я думаю знают все.

>Мне это говорит лишь о том, что в "мыскле" эти фички появились ну очень давно и работали штатно из коробки, а в постгресе они стали появляться заметно позже, и по началу были в виде разнокалиберных довесков, сработанных топором и напильником. Нечем гордиться, короче.

Уважаемый! Неважно что и у кого появилось раньше. Важно то и только то, что есть сейчас.

Сейчас никому не интересно где и когда впервые появился механизм epoll. Важно то, что сейчас он есть в ядре linux и его можно использовать.

Андестенд?

Точно также неважно что FULLTEXT search появился в PostgreSQL в 2001 году. На двое 2006 год и технологии уже пять лет. Поймите, прошло ПЯТЬ ЛЕТ.

Тот же epoll в linux появился в 2002 году, но никто не орет что epoll плохая технология раз его не было в minix.

В отличие от MySQL, у которого сейчас куча детских проблем с теми же VIEWS, CHECKS, CONSTRAINTS, TRIGGERS и ХП, у PostgreSQL все это давно есть и работает.

P.S. И расскажите мне, как сделать *работающий* FOREIGN KEY на таблицу, по полям которой построен FULLTEXT INDEX. Просьба не плакать о том, что InnoDB не умеет FULLTEXT, а MyISAM - FOREIGN KEYS.

> Во имя Патрика!

И PHP пророк его!

> Когда подрастете и выйдете из возраста сайтов "Я и моя собака", вот тогда и поговорим.

О. Вы таки были на моём сайте? Он напейсан на PHP, да.

> В отсутствие AS, СУБД без контроля ссылочной целостности - просто набор несвязанных данных. Каша. Помойка.

Я тоже ещё раз повторю медленно: Эта фраза для меня не имеет смысла,
ибо то же самое можно сказать, про внутренние механизмы контроля в СУБД.
Без них база превращается в набор несвязанных данных. Да, без ног нельзя
ходить, и что? Я говорю про наличие AS, а вы мне про его отсутствие.

> Поскольку во всех мало-мальски серьезных проектах доступ к СУБД ведется разными клиентами

Кто сказал, что это правильно? В доме несколько дверей, причём охраняется только одна, а при желании можно заходить и в окна.

> В серьезных проектах этот слой абстракции будет ОЧЕНЬ сложным.

Это если писать на триггерах ;) Вообще программа по определению
усложняется в разы, если код разнесен по разным хранилищам и писан
на разных языках.

> Если бизнес-логика в системе зашита в AS, придется переписывать код самого AS,

Ну да, маленький кусочек кода, если AS правильно спроектирован.

> всех вспомогательных сервисов

А это если неправильно ;) А вообще чушь какая-то. Чем принципиально
код в AS может так сильно отличаться от кода тиггера?

> Писать триггеры ПРОЩЕ чем переписывать уровень абстракции СУБД.

А при чём тут уровень абстракции СУБД? Куда-то вас унесло, уважаемый.

> Слушай тема - WHERE CLAUSE тоже лишняя вещь (это в тему вьюшек). Нах он сдался - усе пофильтруем в middle tier. О, проснулся. Жабокодеры именно так и делают. Ужас

по поводу производительности sqlite:
http://sqlite.org/speed.html

так, что пук в лужу?

и еще http://www.phpworld.ru/sqlite/

Ваш выбор в системе хранения данных даже не MySQL, присмотритесь к dbase или paradox, хотя dbase для вас предпочтительнее. Например какой нибудь foxpro быстрее любой другой СУБД сделает select * from <таблица>, а остальное на AS положите.

> Зачем этот монстр? Во имя чего? Для большинства задач хватает MySQL и PHP.

Я бы сказал, что, к огромному сожалению, большинство "разработчиков" (стремитьса к "компьютерщиков"), не знает и, что хуже всего, не хочет знать, ничего, кроме MySQL и PHP.

>Я тоже ещё раз повторю медленно: Эта фраза для меня не имеет смысла, ибо то же самое можно сказать, про внутренние механизмы контроля в СУБД.

>Без них база превращается в набор несвязанных данных. Да, без ног нельзя ходить, и что? Я говорю про наличие AS, а вы мне про его отсутствие.

Еще раз: не всегда можно обеспечить работу с базой только посредством AS. В теории - да, все можно сделать в AS. На практике - почти всегда нет. Ну не получается (во всяком случае пока еще ни у кого не получилось) сделать серьезный проект в виде монолита.

>> Поскольку во всех мало-мальски серьезных проектах доступ к СУБД ведется разными клиентами

>Кто сказал, что это правильно? В доме несколько дверей, причём охраняется только одна, а при желании можно заходить и в окна.

Уважаемый! Любая, повторяю, ЛЮБАЯ мало-мальски сложная система, биллинг ISP, например, имеет несколько источников и приемников данных. Одним AS дело никогда не ограничивается. А коли так, то надо делать слой абстракции и работать только через него, а это сложно, тяжеловесно, и дорого. А в ряде случаев просто невозможно. Либо выносить бизнес-логику в базу и делать ее интерфейс максимально абстрактным.

>Это если писать на триггерах ;) Вообще программа по определению усложняется в разы, если код разнесен по разным хранилищам и писан на разных языках.

Вы слабо представляете себе современные технологии. Для того же PostgreSQL триггеры можно писать на Python, C, Perl, PHP, Java. На этих же языках можно делать и остальной обвес. Так что увы, Ваш аргумент несущественен.

>Ну да, маленький кусочек кода, если AS правильно спроектирован.

И регрессионное тестирование всего кода AS, выкладывание новых бинарников по клиентам? И насколько это затратнее создания триггера и обновления только заданной функциональности.

>А это если неправильно ;) А вообще чушь какая-то. Чем принципиально код в AS может так сильно отличаться от кода тиггера?

Тем, что триггер отлично оформляется в виде отдельного модуля, и это общепринятая практика, а вот чтобы подобная функциональность для AS оформлялась в виде отдельной .so / .dll я не видел. Если Вы видели, приведите ссылку на описание подобного работающего проекта.

P.S. Вас не затруднит дать здесь ссылку на выполненные Вами проекты, относящиеся к этой тематике?

>по поводу производительности sqlite:

Тест некорректный. Это последовательные (в один поток) запросы. Интересуют именно конкурирующие. Когда две сотни пользователей одновременно делают простые запросы к одним и тем же таблицам.

> Возможности вполне подходящие для написания простых проектов.

Это ответ из разряда: "-чем лучше? -чем линукс!" ?

> И в некоторых случаях выбор MySQL - единственнно правильное решение.

Случаи в студию. Я еще могу представить случаи когда это "достаточно подходящее решение" но чтобы mysql был "единственно правильным" - это как-то с трудом.

>Другое дело, что сейчас MySQL усложняется в ущерб производительности, что очень и очень плохо.

Ф точку. Пока он был совсем надобазой с ограниченными возможностями и летал - был определенный смысл, если уж хотелось чего-либо SQLного супербыстрого. Но природа текущих изменений такова, что он становиться таким же якорем как и остальные, а по фичастости до остальных ему как раком до парижа.

>Эта фраза для меня не имеет смысла,

Точно подмечено ;)

>В доме несколько дверей, причём охраняется только одна, а при желании можно заходить и в окна.

Вот потому и накладывается констрейнт на _данные_, чтобы все входы были охраняемые.

>Вообще программа по определению усложняется в разы, если код разнесен по разным хранилищам и писан на разных языках.

Апределение в студию.

>Ну да, маленький кусочек кода, если AS правильно спроектирован.

Практическое большинство валидаций целостности данных в middle tier сложнее декларативной защиты базы.

> А при чём тут уровень абстракции СУБД? Куда-то вас унесло, уважаемый.

Правильно его унесло. Он говорит о том что если проверку на инварианты выносить кудато в снаружу, нужно вводить еще один уровень абстракции, который отвечает за непротиворечивость данных.

PS: Уж не говоря о том что задумайтесь на секунду скока вам придется поганять данных по сетке из базы, чтобы проверить это все в middle tier.

>Случаи в студию. Я еще могу представить случаи когда это "достаточно подходящее решение" но чтобы mysql был "единственно правильным" - это как-то с трудом.

Пожалуйста: в простых CMS, предназначенных для работы на дешевых массовых хостингах, где есть только PHP и MySQL, MySQL - единственно верное решение: делать все на файлах долго и дорого, а использовать другие СУБД нет возможности.

Разумеется, для большинства "взрослых" задач такая СУБД не подходит, но это в ряде случаев и не требуется.

> Пожалуйста: в простых CMS, предназначенных для работы на дешевых массовых хостингах, где есть только PHP и MySQL,

Из этого проистекает не единственная правильность, а отсутсвие выбора. Если хостинг на венде, из этого же не проистекает, что венда - "единственно правильное" решение?

>Разумеется, для большинства "взрослых" задач такая СУБД не подходит, но это в ряде случаев и не требуется.

То есть все-таки просто "достаточно подходящее".

>Так какие там возможности то в mysql?

Как раз таки наоборот, в mysql их считай нет.

> Например какой нибудь foxpro быстрее любой другой СУБД сделает select * from <таблица>, а остальное на AS положите.

Правильно. Наконец-то и до вас дошла такая простая истина ;) xbase и
сейчас живее всех живых. Это проклятые маркетологи с недоучёными
однажды сговорившись решили похоронить его в молодом возрасте.
Что они дали взамен? Убожеский сиквель - велосипед, который каждый
производитель СУБД строит по своему.

>>В доме несколько дверей, причём охраняется только одна, а при желании можно заходить и в окна.

> Вот потому и накладывается констрейнт на _данные_, чтобы все входы были охраняемые.

Согласен. Это один из вариантов стратегии защиты данных. Один из.
И я не рискнул бы утверждать, что лучший... Слабые места сразу
бросаются в глаза. Вот во все эти двери и окна одновременно стали
ломиться клиенты. Что делается с такой СУБД? Она встаёт раком.
У ней нет возможности распараллелить проверку входящих данных, что
элементарно достигается средствами AS.

> PS: Уж не говоря о том что задумайтесь на секунду скока вам придется поганять данных по сетке из базы, чтобы проверить это все в middle tier.

Ровно наоборот. Когда проверка происходит на уровне AS, некорректные и противоречивые данные просто не доходят до БД, они срезаются на уровне AS. Задумайтесь об этом на секунду ;)

>Согласен. Это один из вариантов стратегии защиты данных. Один из. И я не рискнул бы утверждать, что лучший... Слабые места сразу бросаются в глаза. Вот во все эти двери и окна одновременно стали ломиться клиенты. Что делается с такой СУБД? Она встаёт раком. У ней нет возможности распараллелить проверку входящих данных, что элементарно достигается средствами AS.

В этом случае становится раком AS. При этом он очень плохо распараллеливается потому, так как за консистентностью данных следит сам AS и для параллелизма требуется взаимодействие между разными экземплярами AS.

>Ровно наоборот. Когда проверка происходит на уровне AS, некорректные и противоречивые данные просто не доходят до БД, они срезаются на уровне AS.

Беда только в том, что для проверки консистентности набора данных (той же эмуляции FK) их придется сначала выгрести из базы и положить в middle tier.

Задумайтесь об этом на секунду ;)

Не смог удержаться... ;)

> Вот во все эти двери и окна одновременно стали ломиться клиенты. Что делается с такой СУБД? Она встаёт раком. У ней нет возможности распараллелить проверку входящих данных

"версионники"?

> Когда проверка происходит на уровне AS, некорректные и противоречивые данные просто не доходят до БД

Ну блин, очень часто для проверки очень небольшой порции данных необходимо перелопатить намного больше.

>Что делается с такой СУБД? Она встаёт раком.

Она встает раком значительно меньше, чем тогда когда миддл тайер начнет таскать из нее данные чтобы проверить что такого PK не существует или FK указывает в пустоту.

>У ней нет возможности распараллелить проверку входящих данных

Чего чего распараллелить?!

>Когда проверка происходит на уровне AS, некорректные и противоречивые данные просто не доходят до БД, они срезаются на уровне AS.

Какие-то смешные данные. Если они могут провериться даже без участия существующих данных - то это какая-то совсем детская задача. Для тривиальной проверки на существующеий PK в базу приедся таки лезть.

> Она встает раком значительно меньше, чем тогда когда миддл тайер начнет таскать из нее данные чтобы проверить что такого PK

Ну тогда ещё на секунду задумаемся хотя бы о том, что СУБД и AS легко
ставятся на разные машины. Ну хоть с этим не будем спорить? Код проверки
целостности данных не отнимает ресурсы у СУБД, а если отнимает, то
на очень короткие, тщательно оптимизированные запросы. Более того,
открываются такие вкусности, как простое зеркалирование данных, когда
AS синхронно пишет сразу в несколько БД. Да вообще, что непонятно в
принципе "разделяй и властвуй"? Весь Unix построен на этом. Одна
программа - одна функция.

Пример из почтовых серверов. Устройство СУБД, которое вы тут все
отстаиваете - это аналог старичка sendmail - всё в одном. А принцип
органицации СУБД, про который говорю я - это qmail и postfix - модульная
структура с изоляцией отдельных операций в отдельных процесах.

>Ну тогда ещё на секунду задумаемся хотя бы о том, что СУБД и AS легко ставятся на разные машины. Ну хоть с этим не будем спорить?

Отлично. Тогда у нас будет офигенный межсетевой трафик. То, что можно было передать в памяти, теперь будет гоняться туда-обратно по сети. Классно, да.

>Код проверки целостности данных не отнимает ресурсы у СУБД, а если отнимает, то на очень короткие, тщательно оптимизированные запросы.

Кто это Вам сказал, что код проверки целостности будет порождать короткие запросы?

>Более того, открываются такие вкусности, как простое зеркалирование данных, когда AS синхронно пишет сразу в несколько БД.

Это Вы считаете, что самое медленное приложение - СУБД. А если это не так и самое медленное приложение - AS, то ситуация становится прямо противоположной: одна СУБД и несколько AS. Теперь вопрос: как синхронизировать эти несколько AS, если ссылочная целостность реализуется в каждом из них? Писать самому распределенныую систему, да?

Хорошо, как быть с системой, у которой есть несколько разнородных источников и приемников данных? Как делать синхронизацию в этом случае?

>Да вообще, что непонятно в принципе "разделяй и властвуй"? Весь Unix построен на этом. Одна программа - одна функция.

Все верно. Одна программа - одна функция. СУБД хранит данные. Она же должна гарантировать их непротиворечивость. Иначе функция хранения данных не реализуется, потому, что просто данные без взаимосвязи между собой - это не данные, а просто набор байтов. это тоже самое, что не связанный между собой набор блоков на файловой системе. Нет никакой возможности сказать, свободен блок или занят и вообще для чего он.

>А принцип органицации СУБД, про который говорю я - это qmail и postfix - модульная структура с изоляцией отдельных операций в отдельных процесах.

Qmail - это тот, который толком не девелопится, у него кривая лицензия, для того, чтобы к нему прикрутить очередной фильтр, надо подменять qmail-smtpd и делать цепочку таких вот программ? На каждое письмо устраивая по несколько fork? Классно, ничего не скажешь.

Да, если Вас не затруднит, приведите результаты тестов скорости не голого оригинального qmail, а полностью настроенной почтовой системы со спам-фильтром, антивирусом, черными/белыми/серыми списками и авторизацией из LDAP.

>Ну тогда ещё на секунду задумаемся хотя бы о том, что СУБД и AS легко >ставятся на разные машины. Ну хоть с этим не будем спорить?

Да, с этим трудно поспорить... а главное - незачем

> Код проверки целостности данных не отнимает ресурсы у СУБД, а если отнимает, то на очень короткие, тщательно оптимизированные запросы.

"Полюби, Маруся, теоретика, пока его током не убило" (c)

> Более того, открываются такие вкусности, как простое зеркалирование данных, когда AS синхронно пишет сразу в несколько БД.

В контексте фразы я не очень понял, какое отношение имеет проверка целостности в локальном хранилище к распределенной транзакции в целом?

> Да вообще, что непонятно в принципе "разделяй и властвуй"? Весь Unix построен на этом.Одна программа - одна функция.

Именно, а Вы пытаетесь заставить AS заниматься тем, чем ему заниматься совсем не надо. Вынося логику базы в AS, Вы: 1) Изобретаете велосипед, и чаще всего неудачно. Как правило, алгоритмы в базе вылизаны не одним десятком людей и за довольно-таки продолжительное время. 2) Чрезмерно усложняете код AS, увеличивая затраты на сопровождение и поддержку

Вас же никто не призывает отказаться от AS вообще. Речь идет о том, что каждый слой должен заниматься своим делом.

>Возможно. Давно не интересовался вопросом.

ну так чего язык распустил прохожий. иди на йух

>Но помню, что когда в mysql эта фича появилась, в постгресе её в помине не было.

сравнил 1-2 фичи появившиеся в мыскле раньше с 1001 постгри. повеселил офис

Касаемо:

Хорошо, как быть с системой, у которой есть несколько разнородных источников и приемников данных? Как делать синхронизацию в этом случае?

Пример такой системы - биллинг ISP. В котором есть вебинтерфейсы администраторов и пользователей, интерфейс приема платежей, обработчики событий на серверах (порядка нескольких сот серверов), система мониторинга (списание денег за превышение квот), система миграции хостинговых площадок между серверами, доступ средств СОРМ, генераторы отчетов, анализатор сетевых атак на клиентов, система выгрузки данных для бухгалтерского баланса и т.д.

Скажите, Вы и впрямь думаете, что всё это можно запихать в один-единственный AS, размещенный на одной-единственной машине? Если да, значит Вы просто не представляете себе, что такое биллинг ISP. И уж тем более - что такое биллинг ОПСОС.

>Ну тогда ещё на секунду задумаемся хотя бы о том, что СУБД и AS легко ставятся на разные машины

во-во! И то что может быть сделано в локальном процессе базы мгновенно, будет растянуто в несколько сетевых запросов и таскания данных с маршалингом, трансформацией этих данных во вменяемую структууру и обратно.

>Более того, открываются такие вкусности, как простое зеркалирование данных, когда AS синхронно пишет сразу в несколько БД.

Если при этом базы не знают про XA-транзакцию - с такой архитектурой будет только геморой с несинхронными данными. А если у них и так будет один координатор - встает вопрос нахрена эту работу делает какой-то там AS.

>Одна программа - одна функция.

Вот тож. Data integrity control - это самая что нинаесть функция DBMS. А не всяких там AS.

У меня есть предложение закрыть тему Ибо от топика мы отдалились изрядно, а свои мозги другим не вставишь

> Отлично. Тогда у нас будет офигенный межсетевой трафик

Ага, просто мега трафик:
Select count(*) where id = $PK;

Не смешите мои тапочки.

> Кто это Вам сказал, что код проверки целостности будет порождать короткие запросы?

Да вы же и сказали ;) Меня укоряли в том, что (цитирую) "миддл тайер
начнет таскать из нее данные чтобы проверить что такого PK не существует
или FK указывает в пустоту".

> А если это не так и самое медленное приложение - AS

Это не так. Ибо AS, образно говоря, думает головой, а СУБД работает
физически руками, сильно завися от производительности носителей
информации.

> Хорошо, как быть с системой, у которой есть несколько разнородных источников и приемников данных? Как делать синхронизацию в этом случае?

Очевидно. Привести информацию к общему виду. А далее, для AS
совершенно безразличен источник. Он получает стандартные запросы.

> СУБД хранит данные. Она же должна гарантировать их непротиворечивость.

Не должна. Строители строят банк, охранные фирмы охраняют. Попробуйте
соединить их воедино, и расскажите, что получилось.

> Qmail - это тот, который толком не девелопится, у него кривая лицензия, для того, чтобы к нему прикрутить очередной фильтр

Пожалуйста, выключите ваш граммофон, пластинка в нём давно заела.
Postfix сделан по тому же принципу, Sendmail2 - то же (не прошло и 20
лет). Перефразируя известную поговорку: Те, кто не понимает qmail,
в любом случае оказываются перед необходимостью криво повторить его архитектуру.

> Ага, просто мега трафик:
> Select count(*) where id = $PK;
ага round-trip задержка на пустом месте

> Это не так. Ибо AS, образно говоря, думает головой, а СУБД работает
физически руками, сильно завися от производительности носителей
информации.
а какая разница ? все равно этой голове приходится ждать выролнения опреации БД, или ваш AS все синхронизирует в бакграунде и сам реализует механизм транзакций (рапределенных ?) ?

а что вообще за абстрактный AS имеется в виду ? можно конкретнее ...

> а какая разница ? все равно этой голове приходится ждать выролнения опреации БД

Читайте внимательнее, вопрос был о том, кто теоретически может оказаться
самым узким местом - БД или AS. Если AS ждёт БД, моё утверждение
остаётся верным.

>Select count(*) where id = $PK;

Это очень затратная процедура, если нет ключей. Потому как будет Sequence Scan по всей таблице. Или Вы собираетесь индексы все-таки создавать? Забавно, если Вы создаете индексы, чем Вам так мешают внешние ключи? Вы вообще в курсе, как работает механизм Foreign Keys?

>Да вы же и сказали ;) Меня укоряли в том, что (цитирую) "миддл тайер начнет таскать из нее данные чтобы проверить что такого PK не существует или FK указывает в пустоту".

То есть, Вы всерьез считаете, что Select count(*) where id = $PK плюс передача результата на AS будет работать быстрее чем поиск по индексу и высталение флага внутри СУБД безо всякой передачи данных?

>Это не так. Ибо AS, образно говоря, думает головой, а СУБД работает физически руками, сильно завися от производительности носителей информации.

AS, образно говоря, думает головой, порождая огромное количество запросов

>Очевидно. Привести информацию к общему виду. А далее, для AS совершенно безразличен источник. Он получает стандартные запросы.

Так бывает только при рассмотрении сферических коней в вакууме. А в реальности - нет. И не надо про неправильное проектирование. Любая система рано или поздно становится спроектированной неподходящим для текущих задач образом.

>Не должна. Строители строят банк, охранные фирмы охраняют. Попробуйте соединить их воедино, и расскажите, что получилось.

Аналогия неверна. Верная аналогия: банк хранит деньги, он же гарантирует правильность всех проводок.

> Qmail - это тот, который толком не девелопится, у него кривая лицензия, для того, чтобы к нему прикрутить очередной фильтр

>Пожалуйста, выключите ваш граммофон, пластинка в нём давно заела.

А Вы не сравнивайте несравнимые вещи. Мы не о MTA рассуждаем.

>Postfix сделан по тому же принципу, Sendmail2 - то же (не прошло и 20 лет).

Что, по несколько fork на одно письмо, да?

Короче, уважаемый, Вас не затруднит назвать свое место работы и огласить список выполненных проектов?

>>Зачем этот монстр? Во имя чего? Для большинства задач хватает MySQL и PHP.

Приятная субд. Работать легко. Проблем нет. И точена под сервер субд гораздо тщательней нежели M$ $ql. Ежели еще подсчитать бабки...

А мускулу до монстра еще далеко.

>>Тут немного один адепт сначла СКУЭльсервера от микросо

Можно еще попробовать написать триггерок по переккодированию видео, или придумать еще какую нить замечательную задачу не имеющюю ничего общего с хранением данных. А потом спросить. а может ли это сделать субд Имярек.

ЗЫ Постгри может все.

> Забавно, если Вы создаете индексы, чем Вам так мешают внешние ключи?

Ничего забавного. Ибо я говорил, что задача базы надёжно хранить и
быстро отдавать данные. Индексы нужно, собственно, для этого...

> Аналогия неверна. Верная аналогия: банк хранит деньги, он же гарантирует правильность всех проводок.

Ага, а Банк - это надёжное хранилище плюс штат охраны плюс штат
менеджеров. В таком контексте БД плюс AS чем отличаются? Банк может
сменить охрану? Банк может перевезти деньги в филиал? А ваша СУБД
может позволить себе замену своих функциональных модулей?

> Мы не о MTA рассуждаем.

Аналогия та же. Речь идёт о модульности, возможности замены
функциональных блоков.

> Что, по несколько fork на одно письмо, да?

Да. В каком веке остановилось ваше самообучение? Линукс ветки 2.4
на железе 5-летней давности мог делать до 10 тысяч форков в секунду.
Ваши каналы просядут раньше, чем вы заметите замедление на форках.
Ладно qmail не нравится, но вот же смешное дело - в postfix'e та же
схема ;)

вранье.

постфикс форкается, обрабатывает несколько (ТОЧНО НЕ ОДНО) писем, умирает.

а не 1но письмо, 1ин форк

> Читайте внимательнее, вопрос был о том, кто теоретически может оказаться самым узким местом - БД или AS. Если AS ждёт БД, моё утверждение остаётся верным.

В общем это зависит от сложности бизнес логики VS обема данных. Другое дело что в вашей схеме, при сбалансированном кол-ве бизнес логики и данных, БД стоит в 90% idle (запросы от AS ведь простые, целосности данных нет) и с нагруженными дисками, а AS ровно наоборот (т.к. помимо бизнес логики он еще и целоснотью данных занимается). При этом в бонус получаем нехилый round-trip.

А вот если бы БД занималась целоснотью данных то нагрузка была бы распределена куда равномерней и запросов было бы куда меньше (соотвественно оверхед round-trip меньше).

Вобщем так почти никто не делает.

Все сказал правильно, а вывод сделал неправильный:

>Вобщем так почти никто не делает.
>ed * (*) (26.05.2006 6:11:03)

Так делает ___куча___ народу. У кого ума не хватает, кому используемая технология (мыскль) не позволяет. Убого это, но у них выбора нет :(

> задача базы надёжно хранить и быстро отдавать данные. Индексы нужно, собственно, для этого...

Если у тебя уже есть индекс, зачем ты проверяешь PK на middle tier? Это ведь _минимум_ одно лишнее обращение к базе на каждое размещение данных. И так для каждого столбца. Плюс еще FK.

И заметь, тебе для этих проверок придется писать код. Кучу кода. Все эти запросы, сравнения, множественные обработки аварийных ситуаций... Вместо коротеньких PRIMARY KEY (Id) и REFERENCES OtherTable (OtherId) в процессе создания таблиц.

> А ваша СУБД может позволить себе замену своих функциональных модулей?

Уволить "штат менеджеров, пересчитывающих деньги" (индексы, внешние ключи, хранимые процедуры, триггеры, представления, да хоть типы данных) и "нанять новых"? Легко.

> Аналогия та же. Речь идёт о модульности

Аналогия у тебя хромает. RDBMS без средств контроля целостности и непротиворечивости данных -- это битая файловая система: что-то читается, что-то пишется, только жопа наступает очень быстро. ;)

> Так делает ___куча___ народу. У кого ума не хватает, кому используемая технология (мыскль) не позволяет. Убого это, но у них выбора нет :(
в так случаях полноценный AS middle teir редко кто использует, все делают из presentation поэтому и "почти никто".

>И заметь, тебе для этих проверок придется писать код. Кучу кода. Все эти запросы, сравнения, множественные обработки аварийных ситуаций... Вместо коротеньких PRIMARY KEY (Id) и REFERENCES OtherTable (OtherId) в процессе создания таблиц.

да что ему объяснять. быдлопрограммеру нравится каждый раз писать и переписывать какую то часть движка совеременных субд. то что его код не оттестирован и не проверен временем его не волнует. остается лишь пожалеть тех для кого он пишет, если конечно эти мифические клиенты вообще существуют :)

>Ничего забавного. Ибо я говорил, что задача базы надёжно хранить и 
>быстро отдавать данные. Индексы нужно, собственно, для этого... 

Еще раз: вы в принципе представляете себе современную реализацию 
FOREIGN KEYS и как она (реализация) связана с обычными индексами в 
таблице.

>Ага, а Банк - это надёжное хранилище плюс штат охраны плюс штат 
>менеджеров. В таком контексте БД плюс AS чем отличаются? Банк может 
>сменить охрану? Банк может перевезти деньги в филиал? А ваша СУБД 
>может позволить себе замену своих функциональных модулей? 

Уважаемый! Основная функция банка - не депозитарий, а система 
проводок платежей. БД - это, по аналогии, отделение банка, проводящее 
платежи, AS - офис с операционистами, принимающими бумаги.

>Аналогия та же. Речь идёт о модульности, возможности замены 
>функциональных блоков. 

ну и?
CREATE OR REPLACE FUNCTION .....
DROP TRIGGER .....
CREATE ... TRIGGER ....

>Ваши каналы просядут раньше, чем вы заметите замедление на форках. 
>Ладно qmail не нравится, но вот же смешное дело - в postfix'e та же 
>схема ;) 

Тольок не при условии fork + exec. Чистый fork - да, еще лучше, если 
будет rfork. А вот fork + exec на нагруженной системе - это дисковые 
операции, много дисковых операций. Так что  10000 fork сделать не 
выйдет, ну не прочитаются данные за такое время с диска.


P.S. Вас не затруднит назвать свое место работы и огласить список выполненных проектов?