> 2 hbee: Но вы, я думаю, согласитесь, что это не Application Server? Это скорее Application который выполняется на Server. Я более чем уверен, что вашу задачу возможно решить с помощью stored procedure.

Согласен - возможно. Не буду больше офтопить.

>кури: >http://directory.google.com/Top/Computers/Software/Databases/PostgreSQL/Repli...

Детский сад, последний апдейт сайта 2 года назад, про 7.3 они даже не слышали ничего. _____________________

Ну бля не поймешь этих мускульщиков то что два года назад это уже работало в постгресе это недостаток знач.

Коллеги, откуда столько злости по отношению друг к другу? Я думаю что нормальный девелопер должен использовать тот продукт, который больше всего подходит для решения его задачи, а не вцеплятся в один подвернувшийся, прикладывать его туда и сюда, а потом всем с пеной у рта доказывать что он самый крутой, а всё остальное г...

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

Нет ничего отвратительнее фанатичных приверженцев ублюдочного ООП... :(

А plpgsql в натуре идёт нах. Потому как pltcl есть.

без комментариев.

>кури: >http://directory.google.com/Top/Computers/Software/Databases/PostgreSQL/Repli...

>Детский сад, последний апдейт сайта 2 года назад, про 7.3 они даже не слышали > ничего. _____________________

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

Ты может не заметил разницы между встроенной в сервер функциональностью (MySQL) и написанной на tcl/tk приблудой, про которую уже два года назад забыли авторы, и которая с 7.2 работает только после доводки напильником, что уж говорить про 7.3?

>Коллеги, откуда столько злости по отношению друг к другу?

Не принимайте близко к сердцу. Здесь люди собираются .. хм... разные..

:)))

Да вообщем-то понятно, народ молодой, горячий. Однако всё-таки я ожидал увидеть здесь linux community, а не чёрный флейм.

По поводу фич, это всегда приятно, но все ли они так нужны? А с другой сторны, чем больше возможностей тем больше ошибок. Хотелось бы услышать success story на тему: в продукте есть такая возможность, нет её больше нигде, я её использовал и получил отличный результат. Я например, не использую и 30% возможностей своего сотового, имею ли я право хвастатся, что у меня есть игрушки, календарь, Blue Tooth и ещё много чего. IMHO нет - значит я просто переплатил за то что мне не надо.

P.S. по поводу репликации Postgres-а читать тут: http://gborg.postgresql.org/project/pgreplication/projdisplay.php

Пост для того гения "нормального OO ( D )", который изрёк:

> plsql плох:
> - отсутсвием нормального OO ( D ) - oтсутсвием нормальной
> обработки exceptions ( c наследованием ) - отсутсвием
> возможности создавать нормальные и удобные структуры данных

А Вы никогда не задумывались, почему одни языки реализовывают парадигмы ОО программирования, а другие - логического, или, скажем, функционального? Может, вы хотите сказать, что C++ (Java и т.п.) - это круто, а Lisp - это аЦтой, потому что в нём нет "нормальной обработки exceptions ( c наследованием )"?

Просто ЛИЧНО у меня сложилось такое впечатление, что Вы просто просмотрели доку по plsql, не увидели умных слов, типа "OO (D)", и решили вякнуть, что plsql - "плох"...

wild

з.ы. Кстати, а кто вам мешает писать сохранёнки для Постгреса на любом другом языке?

> Кстати, а кто вам мешает писать сохранёнки для Постгреса на любом другом языке?

Correct. На плюсах пишется на ура.

>> Кстати, а кто вам мешает писать сохранёнки для Постгреса на любом другом языке? >Correct. На плюсах пишется на ура.

ОК через надцать лет посгрес просел, беру оракл и ... задница :) или в соседнем офисе купились на M$ SQL ... и чо, бум все с тем же энтузиазизмом переписывать и докупать M$$$$$ ???

логика от стоража должна быть отделена

>> Кстати, а кто вам мешает писать сохранёнки для Постгреса на
>> любом другом языке?
> Correct. На плюсах пишется на ура.

Аха. Пишется. Для любопытных:
http://postgres.org/users-lounge/docs/7.3/postgres/xfunc.html
Это для любителей "OO (D)".

А для любителей писать свои сохранёнки всё же внутри SQL-инструкций на выбор: PL/pgSQL, PL/Tcl, PL/Perl, and PL/Python.

> ОК через надцать лет посгрес просел, беру оракл и ... задница :) или в соседнем офисе купились на M$ SQL ... и чо, бум все с тем же энтузиазизмом переписывать и докупать M$$$$$ ???

Это аргументация того же рода, что через xx лет язык программирования на котором ты писал AS просел, "и чо, бум все с тем же энтузиазизмом переписывать и докупать M$$$$$ ???"

> логика от стоража должна быть отделена

Логика, простите, чего? Уточните, плиз...

Wild

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

1) Структура базы. Сидит разработчик (концептуальный) и в UML рисует структуру данных. Она не будет разной под разные платформы, так как разрабатывается _унифицированной_.
Да, как бывший админ, я знаю что "что угодно можно нагнуть как угодно". Но это извращение и у меня это прошло. =)

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

3) Бекапы и прочие описанные фичи. Разделим на 2 группы - безусловно полезные и ИМХО бесполезные.
Да репликация, хот-бекап, кластеры, логгинг - это безусловно круто. Мало того - это зачастую наверняка определяет платформу для разработки.
Но всегда есть возможность реализовать свое и тем более, что никто не мешает, а потом можно смело добавить это как очень полезную фичу, которая работает ничем не хуже, чем передовые разработки IBM и Oracle. Трудозатраты есть - платите деньги.

Про гуи - как говорят в той-же Одессе "не смешите мои кеды!".
(скиппед как я тут лихо бил себя пяткой в грудь).
Суть:
Каким бы крутым гуй не был, он все-равно не заменит голову и руки.

ИМХО. Изначально привязываться к какой-либо платформе - это обрекать свой проект на будущую зависимость от этого продукта. Шире надо смотреть(или ширее ?). Те же года 3-4 (а может больше ?) назад все кипятком от Информикса исходили... Теперь MySQL. Вот тут начальник соседнего отдела еще не пробовал, но уже все уши прожжужжал "Cache ! Cache5 ! В десять раз быстрее Оракла!". Поставим - посмотрим.
"Все проходит, и это тоже пройдет."

>А Вы никогда не задумывались, почему одни языки реализовывают парадигмы ОО программирования, а другие - логического, или, скажем, функционального? Может, вы хотите сказать, что C++ (Java и т.п.) - это круто, а Lisp - это аЦтой, потому что в нём нет "нормальной обработки exceptions ( c наследованием )"?

ИМХО

Многие из здешних парадигмы lisp поймут только после смерти

<Цитата> Кстати, а кто вам мешает писать сохранёнки для Постгреса на любом другом языке?

Correct. На плюсах пишется на ура.</цитата>

Мешает вот что:

1) Отладка. Серьезную вешь отладить внутри сервера бд - это вам не gdb a.out..

2) Скажем получить code coverage такой процедуры при тестировании - вообще проблема

3) Есть возможность внутри СУБД словить sigsegv с непредсказуемыми последствиями для данных

to Sun-ch (*) (2003-04-24 16:56:00.654724)
> Многие из здешних парадигмы lisp поймут только после смерти

Поэтому и постят всякую фигню... :)

Wild

> 1) Отладка. Серьезную вешь отладить внутри сервера бд - это вам не gdb a.out..

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

> 2) Скажем получить code coverage такой процедуры при тестировании - вообще проблема

Скажете тоже. ничем не отличается от coverage обычного a.out. Обеспечьте вызовы триггера и все. Если вы знаете, зачем писали триггер, то и на тестах ситуацию воспроизвести сможете.

> 3) Есть возможность внутри СУБД словить sigsegv с непредсказуемыми последствиями для данных

sigsegv ничем не отличается от других программистских ошибок. триггер на pl-языке тоже может напортачить немало. кстати postgres откатывает транзакции с sigsegv вполне успешно (без потерь данных, правда сессии все открытые закрывает...). Вообще - бояться sigsegv это значит и самого кода базы опасаться надо, его тоже не на небесах пишут...

>1) Структура базы. Сидит разработчик (концептуальный) и в UML рисует >структуру данных. Она не будет разной под разные платформы, так как >разрабатывается _унифицированной_.

ЫЫЫ!!! Ж8-[] Что действительно кто ещё пишет серьёзные проекты на чистом SQL 92????

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

Примеры! Давайте примеры! Я не видел ещё пока подобных продуктов. Очень напомнает старую песню про BDE.

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

Так вы придёте к тому что реализуете свой SQL сервер. Совсем недавно я имел неприятную переписку с разработчиками некого TA Billing-а, так вот они мне доказывали, что для биллинга SQL и вовсе не нужен, у них своя база, заточенная под нужды биллинга и всё ок!

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

Такой подход годится только для мелких проектов. Если вы разрабатываете что-то серьезное и тяжелое, то в тонкости конкретной базы влезь так или иначе придется, реалии жизни таковы. Даже SQL92 поддерживается далеко местами разными СУБД. Ценность общего subset фич сводится к тривиальным таблицам и несложным запросам и практически равна нулю.

<цитата> > 1) Отладка. Серьезную вешь отладить внутри сервера бд - это вам не gdb a.out.. Никаких проблем. брекпойнты работают, gdb работает, аттачиться к форканым процессам тоже умеем. > 2) Скажем получить code coverage такой процедуры при тестировании - вообще проблема Скажете тоже. ничем не отличается от coverage обычного a.out. Обеспечьте вызовы триггера и все. Если вы знаете, зачем писали триггер, то и на тестах ситуацию воспроизвести сможете. </цитата>

Про code coverage вы правы. Я неподумав это написал. А про отладку - ну не gdb же единым.. А Valgrind например?

<цитата> sigsegv ничем не отличается от других программистских ошибок. триггер на pl-языке тоже может напортачить немало. кстати postgres откатывает транзакции с sigsegv вполне успешно (без потерь данных, правда сессии все открытые закрывает...). </цитата>

sigsegv - это просто для примера. Смысл в том, что на С/С++ можно на изком уровне напортачить так, что завалится весь сервер ( который обслуживает не только ваши задачи). Например - если ошибиться в выделениях/освобождении памяти.

Про откатку транзакций с sigsegv - если postgres запускается с -o -F (чтобы он пошустрее работал) - все не так безоблачно.

to walrus (*) (2003-04-24 17:01:39.264331)

> Мешает вот что:
> ...........

А мне яйца мешают танцевать... :))) Это если шутить. А если серьёзно, то "идеален только Бог". На самом деле, при желании, можно придраться (найти недостатки, etc) в чём угодно. Я, например, считаю, что первичная обработка данных должна производится СУБД. Причины навскидку:
1. Все операции с данными, которые влекут изменения других данных под воздействием правил, заданных при проектировании структуры БД должны производится СУБД. Но некоторые личности путают логику хранения данных и логику работы приложения (модифицирующего эти данные) и предлагают обе "логики" выполнять на сервере приложений. Имхо - концептуальный бред. Хотя, никто не мешат это реализовать... Просто надо _чувствовать_ эту разницу, чтобы делать Грамотно.
2. Предположим, СУБД крутится на выделенном сервере. Если логику положить на сервер приложений, то представте себе, как будет отрабатывать программный foreign key, удаляющий один из корневых узлов дерева (почему бы и нет? есть отличные методы реализации деревьев в SQL...): в элементарном виде, рекурсия, делающая N выборок для N узлов (поправте, если ошибаюсь) + ещё N операций удаления для N узлов (алгоритм "в лоб"). Прикинте, какой будет траффик!!! Сколько такая задача будет выполняться на больших данных? А ведь другие пользователи РАБОТАЮТ с данными, которые сейчас удляются! Может, всё-таки сделать это такими "ненужными фичами", как внешние ключи, триггеры и сохранёнки? Всё быстрее будет, не правда ли?
Можно конечно сказать, что задача "уникальная", но, сами понимаете, если поморщить лоб, то можно ещё десяток примеров придумать.
3. ЦЕЛОСТНОСТЬ ДАННЫХ, ГАРАНТИРОВАННОЕ СУБД! Если мы связываем две таблицы внешним ключом, то ни при каких условиях эта связь не нарушится. А если делать это на сервере приложений, то надо писать _отдельный_ "памперс", гарантирующий эту целостность.

Но! Как правильно вы и указали, в случае Постгреса писать сохранёнки на С геморно. Так оно и есть. Всегда нужно уметь сбалансировать между "концепциями" и "реальной жизнью". И не кидаться в крайности, типа "сохранёнки - для лохов", как тут некоторые делают... И всё будет ОК.

Wild

> Про code coverage вы правы. Я неподумав это написал. А про отладку - ну не gdb же единым.. А Valgrind например?

Да неважно чем, хоть purify. Смысл в том, что отлаживать можно. Я вот правда свой собственный код как-то не отлаживал так жестко, ибо при глюках обычно примерно самому понятно, что скосячилось. А вот с посторонним кодом без отладчиков никуда..

> sigsegv - это просто для примера. Смысл в том, что на С/С++ можно на изком уровне напортачить так, что завалится весь сервер ( который обслуживает не только ваши задачи).

Ну вообще-то не весь, ибо postgres форкается, и только свою копию сервера вы и завалите... Хотя остальные тоже почувствуют неудобства, как я говорил. Кроме того, это все прекрасно осознают, и именно поэтому C не является trusted language для функций базы (флаг есть специальный) и создавать такие функции может только superuser. Функции на SPI фактически являются кусками сервера, поэтому и отношение к ним должно быть, как к самой базе :) Как говорится, есть механизм, есть гибкость, есть ограничители, а если вы туда лезете, то берите ответственность на себя :-)

Присоединяюсь к защитникам триггеров/хранимых! Ещё пара примеров:

1. Расчет процентов - берем счет, вытаскиваем по нему проводки/остатки за период, умножаем на кол-во дней, на процентную ставку, делим на период расчета, сохраняем всё что посчитали. Повторяем 1000, нет, 10000 раз. При выполнении этой логики на клиенте и в БД разница в скорости - в 10-100 раз! Проверено на реальной БД.

2. Бухгалтерская проводка - сумма переводится с одного счета на другой, при этом, естесственно должны пересчитаться остатки/обороты по обоим счетам. Самый простой и надежный способ - делать это триггером при INSERTe или обновлении поля статуса. Логика триггера - тривиальная. Логика на любом клиенте - тоже (вызов INSERT|UPDATE)

3. Почему бы не взглянуть на проблему с другой стороны? Т.е. рассмотреть не одно приложение поверх нескольких СУБД, а несколько клиентов к одной БД ( на С/С++/Java/Python/etc ). IMHO, на вопрос, что быстрее загнется - ваша СУБД или ваш любимый язык, правильный ответ - скорее всего они оба переживут ваше приложение, если вы не будете его постоянно доделывать/переделывать. При использовании хранимых процедур/триггеров можно отделить поддержку логической целостности БД от бизнес-логики. А бизнес-логику (обзовем её Б/Л) вынести вынести в отдельную библиотеку, м.б. даже (сейчас валенки полетят!) на скриптовом языке.

Тогда:

а) легко отлаживать/сопровождать/переделывать быстро меняющуюся бизнес-логику

б) масштабируемость - можно библиотечку с Б/Л запускать параллельно на нескольких серверах /"толстых" клиентах, т.к. за целостность БД отвечает код в БД

в) поверх можно сделать кучу совсем "тонких" клиентов на любых языках/платформах.

Этот подход, конечно, не панацея, но заслуживает рассмотрения и годится для многих средних и "полутяжелых" проектов.

> Если вы разрабатываете что-то серьезное и тяжелое, то в тонкости конкретной базы влезь так или иначе придется, реалии жизни таковы.

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

> Но некоторые личности путают логику хранения данных и логику работы приложения

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

> о представте себе, как будет отрабатывать программный foreign key, удаляющий один из корневых узлов дерева

Зачем представлять, если можно наблюдать реально работающие
вещи, которые успешно справляются с этой "проблемой".

> ЦЕЛОСТНОСТЬ ДАННЫХ, ГАРАНТИРОВАННОЕ СУБД!

А если в данный конкретный момент проверка целостности не требуется? Например, при заливке огромной партии новых, уже
проверенных на целостность данных. Можно конечно подождать
пару суток... а можно дописать пару строчек в сервере
приложения ;)

>Именно поэтому думающие наперед люди вставляют между базой и клиентом >сервер приложений.

Совсем не для этого придумали сервер приложений, а для того, чтобы вынести бизнес логику из клиента, и исполняемые процедуры в коде базы прекрасно вписываются в сервер приложений.

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

Да не бывает таких приложений :) В первую очередь потому что потребителю это не нужно, а срества на разработку и сопровождения возростают многократно. К тому же не бывает таких Application Servers. В любом случае приводите примеры! Иначе заявления получаются не аргументированные.

> Некоторые личности путают хранение данных с логикой. Нет никакой логики хранения данных. Есть правила их хранения, описание того, что и где хранится.

Ну дык и храните данные в голых файлах! Нах вам СУБД вообще?

> Любая логика относится к компетенции сервера приложений.

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

> Зачем представлять, если можно наблюдать реально работающие вещи, которые успешно справляются с этой "проблемой".

Не видел таких. Примеры? То, что вы и прочие студенты написали на коленке, не канает.

> А если в данный конкретный момент проверка целостности не требуется? Например, при заливке огромной партии новых, уже проверенных на целостность данных. Можно конечно подождать пару суток... а можно дописать пару строчек в сервере приложения ;)

Попал пальцем в небо :-) dump/restore механизм есть в каждой базе; как думаешь, там каждая строчка обнюхивается триггером? ;-) В Postres вообще все триггеры можно отключить одним запросом и восстановить потом другим. Короче, не в тему пример.

>Роль триггеров исполняет application server. И докажи, что это неправильно.

лехко 1)вот полез к примеру господин Криворучко ж-) мимо аппликейшен сервера чтото в базе поправить с триггерами - пофиг без них - жопа 2) надо на 1 инсерт делать еще кучу модификаций в разных таблицах аппсервер сделал инсерт и тихо издох опять то же самое

Давно не видел такого полезного обсуждения... Недавно начал интересоваться созданием бизнес-приложений. Теперь есть о чем поразмыслить и стало яснее: в какую сторону смотреть... Спасибо огромное ребята, что не поскупились на инфу, и не перевели это дело в жуткий флэйм, которого тут много...

mysql war

<цитата> лехко 1)вот полез к примеру господин Криворучко ж-) мимо аппликейшен сервера чтото в базе поправить с триггерами - пофиг без них - жопа </цитата>

такое возможно только при безбашенном сисадмине. А иначе, кто же его пустит то, Криворучку в базе ковырять? А если уж пускают, то надо быть готовым, что и с триггерами напортачить запросто могут. Вы наверое не триггеры а constraints имели в виду (но в этом случае один хрен - ломать не строить, практически невозможно построить схему БД, чтобы ее нельзя было сломать пакостными ручками)

<цитата> надо на 1 инсерт делать еще кучу модификаций в разных таблицах аппсервер сделал инсерт и тихо издох опять то же самое </цитата>

Обана! А транзакции зачем? они то в логику не входят! Вот транзакции как раз - вполне серверное дело..

<цитата>1)вот полез к примеру господин Криворучко ж-) мимо аппликейшен сервера чтото в базе поправить с триггерами - пофиг без них - жопа

такое возможно только при безбашенном сисадмине </цитата>

Хм, сколько раз я сталкивался с подобного рода криворучками... Кстати они обычно и бывали теми самыми админами, при этом крутили головой и доказывали, что нет, никак не могут они в базе ковырятся, это всё ваша система плохая, а вовсе не я тут пытался отчёт прикрутить. Пришлось даже создавать систему мониторинга и по результатам логов бить по рукам.

> Обана! А транзакции зачем? они то в логику не входят! Вот транзакции как раз - вполне серверное дело..

Я дико извиняюсь, но у вас что, транзакции на уровне AS не используются? типичная банковская операция прибавить-отнять обязана выполняться атомарно. Грубо говоря, транзакция это не мелкая единица работы, и куча бизнес-логики ей зачастую должна быть обернута...

<цитата> Да не бывает таких приложений :) В первую очередь потому что потребителю это не нужно, а срества на разработку и сопровождения возростают многократно. К тому же не бывает таких Application Servers. В любом случае приводите примеры! Иначе заявления получаются не аргументированные. </цитата>

Как это? bea weblogic например. Зайдите на www.bea.com например и посмотрите там success stories или customer testimonials. Да любой EJB контейнер возьмите.. резину ту же, каучуковую (resin от caucho.com).

<цитата> Я дико извиняюсь, но у вас что, транзакции на уровне AS не используются? типичная банковская операция прибавить-отнять обязана выполняться атомарно. Грубо говоря, транзакция это не мелкая единица работы, и куча бизнес-логики ей зачастую должна быть обернута... </цитата>

Извините, не понял Вашу логику.. AS открывает транзакцию, читает/считает/пишет что надо, закрывает транзакцию. Открывать/закрывать транзакцию - дело безусловно подходящее для AS. А вот обеспечивать возможность транзакций - дело для сервера.

The BEA WebLogic Adapter for RDBMS supports the following databases: Oracle 8.x, 9.x Кроме того ещё SAP нашёл и какую-то PointBase, больше не нашёл :( Штука интересная, но работает только под M$ платформу, как я понял. Я правда скорее предпочту OAS этой штуке, ну да не важно.

Каучук работает через JDBC вообще с чем угодно, хоть с Berkly DB :) Не верю я что на нём можно создать реально большое и сложное приложение, работающее с большими объёмами данных, в любом случае ЧТО ВЫ НАПИСАЛИ С ПОМОЩЬЮ BEA и RESIN, под какие задачи, с какими трудозатратами и как это работало. Ecть у меня знакомая фирма, пишут биллинг на J2EE, заявленно, что работает с любой базой, реально же используют только Sybase :)

> 1)вот полез к примеру господин Криворучко ж-) мимо аппликейшен сервера

Аналогично полез он же править триггер...

> аппсервер сделал инсерт и тихо издох

Начнем с того, что вероятность издыхания AS на порядок ниже,
чем издыхания сервера БД. Если AS все же сдох, то автоматически
останавливаются всякие операции с базой. При подъеме AS должен
обнаружить незавершенную транзакцию (мы ведь о серьезных
продуктах говорим) и произвести откат. После этого продолжается
работа в нормальном режиме.

www.forbis.lt

Sistema napisana na Oracle PL/SQL + Forms OOP tam malo - 80% PL/SQL Sistema ustanovlena po moemu v 12 bankah Kogda ja rabotal v banke s nej, ne raz blagodaril boga chto VSIA logika celostnosti dannyh i mnogo bisnes logiki nahoditsia v baze. Ni odin fanatik AS i mnogourovnevyh prilozhenij ne ubedit menia sozdavat' dlia kritichnyh k celostnosti i skorosti finasovyh prilozhenij sviazku Client-AS-DB s bazoj tol'ko kak hranilishe dannyh. Dlia vsego stal'nogo breda tipa internet shopov - pozhaluista.

PS Sam uzhe 5 let na J2EE pishu i 6 mesiac na .NET :) Moda... eptyt'!

2anonymous (*) (2003-04-25 03:28:36.220359)

А никто таких как ты убеждать не собирается. Ты же все равно
все сделаешь по моде, а не по уму.

2 anonymous (*) (2003-04-25 05:01:08.068062) IMHO человек правильные вещи сказал целостность базы ДОЛЖНА контролироваться базой. Все разговоры про то, что с нормальным админом никто не сможет взять sqlplus и поправить базу - пустой треп хотя бы потому что админы приходят и уходят а программа должна правильно работать не зависимо от квалификации админа. а в случае комерческой апликухи вааще задница.

> Начнем с того, что вероятность издыхания AS на порядок ниже, чем издыхания сервера БД.

Гон.

Это у вас AS такой крутой-вылизанный или вы в качестве базы mysql пользуете? :-)

>Нет никакой логики хранения данных. Есть правила их хранения,
> описание того, что и где хранится.
"Что?", "Где?" и "КАК?" хранится.

> Любая логика относится к
> компетенции сервера приложений.
Да ну? А аргументировать?

> Зачем представлять, если можно наблюдать реально работающие
> вещи, которые успешно справляются с этой "проблемой".
Ну, дык... Я ж в конце пункта и написал, что можно сделать что угодно... Только одно из отличий студенческой поделки от серьёзного продукта - это различие в концептуальных подходах на стадии проектирования.

Посмотрите 1С. Первоначально, вся обработка данных происходила на клиенте. Была сетевая версия, подразумевающая единую базу данных на выделенном компьютере (для того, чтобы сделать баланс, надо чуть ли не всю базу по сети перегнать на клиента и на нём обработать). Позже появилась SQL-версия. Вот она уже была концептуально более правильной, хотя далека от идеала... Можно сказать, что идёт интенсивный итеративный процесс разработки: хорошо и правильно, однако...

Посмотрите MBS-Axapta (http://b-tech.com.ua). В трёхслойке: клиент, сервер приложений с БИЗНЕС-логикой и база данных, целостность данных которой обеспечивается самой базой. Красота, однако!

> А если в данный конкретный момент проверка целостности не
> требуется?
Простите, что за бред? Что это значит? Или в вашей БД (если вы ими занимаетесь) с 8.30 до 12.30 данные гарантированно "целые", а с 12.30 до 17.30 - негарантированно? Чушь!

> Например, при заливке огромной партии новых, уже
> проверенных на целостность данных.
Простите, КЕМ проверенных?

> Можно конечно подождать
> пару суток...
Чего ждать?

anonymous (*) (2003-04-25 11:16:07.493651)

забыл подписаться: Wild

Ну так подведите итоги!

минус апсервера - медленей (про трафик смешно :),
еще есть ?

to anonymous (*) (2003-04-25 11:48:30.870452)

> Ну так подведите итоги!
<Обращение ко всем>

Богу - богово. Кесарю - кесарево.
СУБД - хранение данных. Хранение "с умом". Забудте про хранение данных в файлах! Десять лет назад, может, и была потребность следить за целостностью данных на клиенте (или на appl. server'е). Сегодня - 2003 год и прогресс человечества на лицо: теперь за целостность данных следят СУБД - это такие умные программы, написанные умными (правда, не всегда) дядьками для того, что бы избавить программистов (и остальных участников проекта) от изобретения КОЛЕСА. Ну, почему никто ничего не имеет против транзакций (я не говорю про распределённые транзакции), выпоняемых СУБД, но многие вопят против отслеживания целостности данных средствами той же СУБД. Абсурд, знаете ли! Нет, я не против. Давайте в каждый проект будем закладывать изобретение колеса "целостность данных", выделять под него время, ресурсы... К чему мы прийдём? К бардаку и перерасходу ресурсов. Кому это надо? Никому, кто умеет мыслить.
И ещё. Как на счёт одной из основополагающих концепций ООП (для любителей такового): повторное использование кода? Почитайте Буча. Он там русским (как вариант, английским) языком говорит: идеальный проект - это проект по-максимуму собраный из модулей, которые уже реализованы другими разработчиками (это не цитата). Не надо изобретать колесо. Его уже изобрели до вас. Круглым! А при попытках сделать его кустарно, оно, чаще всего, получается в лучшем случае - овальным, в худшем - квадратным. :)

Сервер приложений - для бизнес-логики приложений. В том смысле, что сервер приложений предназначен для манипулирования данными согласно логике работы прилождения. И всё!

</Обращение ко всем>

> минус апсервера - медленей (про трафик смешно :),
кстати, не смешно...

> еще есть ?
Да. Вы когда-нибудь имели дело с распределёнными приложениями? Хотя бы теоритически разбирались? Вам не кажется, что задача сохранения целостности данных (не предиодическая, как тут у некоторых, а постоянная) в случае распределения единой бизнес-логики по нескольким сервера приложений становится слишком геморной?

>Вы когда-нибудь имели дело с распределёнными приложениями?
детям просьба заткнутся и почитать о Transaction Server

еще есть ?

> детям просьба заткнутся и почитать о Transaction Server
1. Рекомендую ещё раз перечитать постинги и самому почитать о Transaction Server. Может, поможет.
2. Скажи, сынок, у тебя хамство - это врождённый порок или приобретёный? Можешь не отвечать. Мне пофигу. Дискуссия закрыта.

Всем успехов!

to Tico>
Примеров не дам, не потому что жадный, а потому что не единственный разработчик, опишу схему:
используется jdbc, и набор драйверов к Oracle, DB2, PostgreSQL, MySQL и ODBC.

to anonymous>
Нельзя написать серьезную разработку не используя тонкостей той или иной СУБД ?

ИМХО. Never say Never, Never say Never again.
Написать можно все. Все зависит от целесообразности затрат на написание "всего". В настоящий момент времени для меня целесообразней держать 1 команду, которая пишет то, что работает везде, чем держать 1 команду для MySQL, 1 для Oracle, 1 для DB2, 1 для PostgreSQL, 1 для Informix, 1 для ODBC - итого 6 команд.
Предвещая вопрос "А почему бы не держать одну команду для mySQL, или Oracle или ... ?"
Отвечу - один клиент сперва установил у себя DB2, а потом попросил написать под него проект, другой сперва установил у себя Oracle и потом попросил написать проект, у третьего нет денег на коммерческую СУБД, но платит в полтора раза больше чем первый и второй за разработку. Сроки еще ни разу не были реальными с точки зрения максимальной подгонки под ту или иную среду. Так что "написал один раз - использую везде".

Запустили.
Померяли.
Рассмотрели возможность модернизации.
Модернизировались. И так по кругу.

теперя процессор стоит гораздо дешевле чем работа команды спецов ...