Оптимальная архитектура БД

> Объясни тогда, зачем такая маразматическая схема? Чем плохо дернуть процедуру и показать результат?
По такой схеме работает одна из баз нашей организации. Соответственно, я хотел понять, "хорошо" ли она работает, а если нет - то как делать правильно.

> Схема страшно неоптимальная и непонятно зачем придуманная
> Почему обычный вывод из ХП - нестандартный для тебя.
ОК. Попробую так.

> Ты прочитай еще раз то, что я написал:
> Исходя из этих критериев, средний слой вообще следует исключить - дублирует сервер. Я как раз и написал, что сервер следует оставить а выкинуть средний слой - объясни, зачем он тебе?
А сервер приложений - это разве не средний слой (middle-tier)? 3-х-звенка в моем представлении это: 1СУБД-2Сервер_приложений-3Клиенты.

> Нда, ну и квалификацию приобретешь с такой архитектурой
Всё когда-то в первый раз :-) ОК. Буду делать, а что получится - посмотрим ;-)

Так ты новое что-то делаешь или так есть?

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

Новое, такого еще нет ;-)

Хобби у меня - по окончании основной работы (после 17_00) заниматься самообразованием :-). Сейчас вот взялся за MSSQL, написанием клиентов и СП под него. Корбу до этого изучил, но без хорошего знания баз делать с ней нечего (разве что значения функции вычислять на СП, а на клиенте показывать график - был такой обучающий пример :-)

По поводу 2-х звенки - простая она слишком. Ни тебе списка подключенных клиентов, ни динамической нагрузки на СП (переброска клиентов, если один из серверов отрубился), много чего нет, да и с СП интереснее ;-)

Нет, не интереснее, зануднее. Это, конечно, если действительно работающую систему писать. А если так, побаловаться, то конечно интересно, пока не надоест вскоре. Я всего напробовался, когда изучал, давно это было..... :))

А что значит переброска клиентов, если один из серверов отрубился)
Это как? Ты с разными серверами БД одновременно работаешь? А данные как синхронизируешь?

много чего нет
Это чего же такого нет? Проблем лишних - да, нет их.

> А что значит переброска клиентов, если один из серверов отрубился)
Это как? Ты с разными серверами БД одновременно работаешь? А данные как синхронизируешь?
Имелось в виду разные сервера приложений :-) Ходят слухи ;-), что CORBA-сервера (в отличие от DCOM) могут одновременно работать, а брокер ORB будет распределять между ними нагрузку и перенаправлять запросы от клиентов наименее загруженному из них (а также, если СП умер, то направлять запросы клиентов на другие СП, причем первые этого даже не заметят). Звучит соблазнительно, хотелось бы попробовать ;-)

Короче от нечего делать можно и странными исследованиями позаниматься



Понятно...........

Короче от нечего делать можно и странными исследованиями позаниматься



Понятно...........

2tygra
Мы пришли к выводу, что если нужно быстренько на коленях
слепить небольшой проект (таблиц 100), который в ближайшем
будущем не будет модифицироваться и развиваться (другими
словами - срок жизни которого порядка 3-4 месяцев - не более),
то согласен - быстрее и проще двузвенки нет ничего.

Для серьезных задач грамотная трехзвенка дает выигрыш на порядки - но это - отдельная тема...

Готов подписаться под каждым ответом Тигры.

BERK. Не забивайте себе голову чесанием левого уха правой рукой, лучше почитайте кого-нибудь из классиков. Структура с форматными таблицами - полный мастдай. Вы новичек, так что поверьте на слово. Когда въедете в SQL, то сами это поймете. Вы не пишете реального проекта. И Ваши вопросы чисто теоретические. SQL - предметная область. Иссследования показали, что цыплята считают матерью первый увиденный ими движущийся обект. Если Вам, к несчастью, удалось в первый раз увидеть ДЕБИЛЬНУЮ базу, то мы вовсе не обязаны разбирать по косточкам ее идиотизм.

А в общем-то, не полный мастдай. Но на подобных схемах зубры себе левую ногу ломают. А на правой, иногда, добиваются поразительных результатов. А иногда и нет. Особенно, когда зубр увольняется, а на его место приходит обычный хороший программер.
Условно, такие структуры называются ОБЪЕКТНЫМИ. Дикая гибкость и дикая сложность. А где сложность, там избыточные накладные расходы. Не оптимально-с. Оптимально только с точки зрения тиражирования решений и сопровождения. См. 1С. И см. топики "Почему тормозит 1С?", Ни в коей мере не наезжаю на продукцию этой уважаемой фирмы. Я учился на ее интерфейсах и ее подход к пользователю является для меня эталоном.

Dkstranger. Новое, не значит эффективное. Неужели Вы не видите варианта, когда сервер трехзвенки задохнется от перегрузки? Конечно, всегда можно прикупить пару процессоров и модулей памяти. Но когда-то слоты закончатся. "Тонкий" клиент, с моей точки зрения, неудачный маркетинговый ход. Но под эту фигню вложено слишком много баксов, что бы так сразу бросить это дело. Не вижу преимуществ трехзвенки, кроме как легкости апгрейда. 100 таблиц - это не показатель.

Если я не прав - аргументируйте. Что делает трехзвенка, что не может двухзвенка? Проекты на слабых каналах не трогаем.

2 dkstranger

Для серьезных задач грамотная трехзвенка дает выигрыш на порядки - но это - отдельная тема...

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