>Я описал ксасическую "3_х уровневую архитектуру" БД-сервер приложений-клиент.
Которую на данный момент можно викинуть на помойку. Она была хороша когда СУБД уровня MySQL т.е. стандарт SQL 89 года.>Давайте ссылки, обосновывайте.
Обсновываю. Коллектор делает одну операцию работы с СУБД такой-то ip зашел на такой то ip по такому-то порту, за такой-то промежуток времени прошло столько-то байт. И все.
В вашей. Сначала запрашивает тарифы. Потом по встроенным в него алгоритмам
подсчитывает сколько денег должен нам клиент за траффик и помещаем в СУБД.
1. 2 раза обращается в СУБД. Кеширование не выход. Когда у вас меняются тарифы вам прийдется принудительно пинать все коллекторы чтобы они взяли новые тарифы.
2. Изменение логики расчета требует изменения клиента. Это очень способствует переносимости.
>1. Запросы написанные под MySQL будут работать на любой современной SQL >СУБД.
Не агрумент. Тогда нет смысла использвать SQL СУБД. С таким же успехом можно пользоваться berkeley db. О чем я уже говорил. У нас на дворе 2004 год. А мы пользуемся версией SQL за 1989 год. И только ради совместимости.
SQL92 четко регламентирует триггеры и хранимые процедуры.
>2. Переносимость хранимых процедур - проблема - необходимо переписывать >весь синтаксис (самый худший вариант).
Ты их писал ??? Хоть одну? Что-то не похоже. Все языки написания хранимых процедур скорее диалекты чем разные языки. И перенести из одной СУБД сравнимой функциональности в другую гараздо проще чем перенос кода с одной ОС в другую или с одной архитектуры на другую.
>3. Хранимые процедуры часто могут вызвать загрузку сервера на 100% что >нелопустимо.
Первое СУБД такой же процесс как и другие и какая загрузка будет это от ОС зависит. Эээ ниразу у меня такого не случалось... Даже при разработке и случайном зацикливании. Может будем писать правильно процедуры?
>И напоследок хочу сказать если наши споры не приведут к результату (т.е.
>опоненты не согласятся с мнением друг-друга) предлагаю начать с простого.
>Делаю все под MySQL(синтаксис запросов).
Тогда извиняйте. Мои наметки для VPN содержат ppp + RADIUS + PostgreSQL
с хранимыми процедурами. Нет смысла начинать с простого. Если сначала хранимые процедуры не внесены в проект, потом не добавить их встанет в написание всего биллинга заново. Реинжиринг только с хранимыми процедурами.
>если по ходу хранимые процедуры будут давать неоспоримое преимущество >(скорость выполнения, объем кода) будем вводить >их.
Как ты это узнаешь если ты их не будешь использовать?
>Но все на отдельном сайте,форуме.
Ждемс.
