Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 17   вперед  Ctrl
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
c127
Guest
2 Yo!

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

Похоже что действительно не понял, поскольку в том же твоем посте такой зарпос приводится и занимает он одну строчку (select client, date, count(*) from table group by client, date). Конечно можно в установке страницы выставить количествово_строк = 1, тогда ты прав, как раз страница и получается.

>а язык он не на размер кода заточен, а на задачи.

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

>такое впечатление что ты про перл ничего не слышал. на нем решение любой задачи будет занимать меньше кода, там просто там одна проблемка write fast, read slow.

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

Я уже многократно приводил ссылку "The Comparation of 7 Languages" (http://www.osp.ru/os/2000/12/045.htm), там, например, питон не проигрывает перлу по количесву кода, а по лучшему результату даже выигрывает (рис.5). Это доказательство того и так очевидного факта, что все-таки не ЛЮБАЯ задача на перле решается меньшим числом строк.

И все-таки, объяснит кто-нибудь, чем же трехзвенка принципиально лучше классического клиент-сервера?
8 окт 04, 02:39    [1017522]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
s79
Member

Откуда: Владивосток
Сообщений: 40
MasterZiv
И только в транзакции. Так что например задача аудита неудачных попыток изменить данные уже практически неразрешима без сторонних системных средств.]

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

Конечная фраза

Пожалуйста не нужно передергивать. Вы утверждали что это можно сделать только сторонними системными средствами. То что вы написали в конечной фразе, это дополнительное условие которое если усложнить можно дописать для Oracle так: тиггер на аудит не используя PL/SQL (т.к. это специальная возможность СУБД ). Всегда стоит рассматривать и учитываь всю полноту возможностей предоставляемых программным средством.
Так что ваше условие необходимости существования хотябы в одном случае триггера выполнено.
8 окт 04, 04:03    [1017529]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
s79
Member

Откуда: Владивосток
Сообщений: 40
такое впечатление что ты про перл ничего не слышал. на нем решение любой задачи будет занимать меньше кода, там просто там одна проблемка write fast, read slow.

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

Господа давайте не затевать holy war еще и по языкам программирования не относящимся к СУБД.
8 окт 04, 04:12    [1017530]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
savage79
Member

Откуда:
Сообщений: 27
c127

И все-таки, объяснит кто-нибудь, чем же трехзвенка принципиально лучше классического клиент-сервера?

Преимущества буду излагать постепенно.
1.
Трехзвенка например вещь необходимая когда нужно интегрировать несколько информационных систем, тогда сервера приложений могут обмениваться данными в асинхронном режиме например по протоколу SOAP.
При этом БД разных информационных систем (ИС) могут быть под управлением различных СУБД.
Это конечно можно делать и с помощью ХП на Java, но не все сервера БД поддерживают Java, далее это будет выполняться в синхронном режиме, а не асинхронном, что бывает полезно при репликации данных между системами без участия человека.
8 окт 04, 09:06    [1017702]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
funikovyuri
Может не до конца понял gardenman но какое такое решение может принять caller если тригер, контролирующий согласованность, считает ситуацию недопустимой?


В принципе ASCRUS ответил правильно. Ошибка в триггере еще не значит, что всю транзакцию нужно откатывать. Все зависит от логики приложения.
8 окт 04, 10:20    [1017951]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
>И все-таки, объяснит кто-нибудь, чем же трехзвенка принципиально лучше классического клиент-сервера?

В зависимости от проекта могут быть разные преимущества.
Но некоторые общие преимущества напрашиваются сами:
Независимость некоторых уровней друг от друга: 1 и 3. Теоретически можно заменить СУБД, а клиентов исправлять не надо - т.е. исправления на серверах приложений и БД.
Вообще если клиенты только интерфейсом занимаются, то при исправлении функционала на среднем уровне опять клиентов исправлять не надо. У нас есть система отчетов (2-звенка) и система WEB (3-звенка Сервер БД, Web-сервер, клиенты) - отчетов. Первую нужно устанавливать вместе с клиентом Оракла на каждый комп клиетского уровня, а на второй можно вообще почти ничего не знать о клиентах.
Это сказывается на сопровождении - этих клиентов может быть очень много или мало, но мерзких - допотопные компы, не известено где стоят, а заглючат не отмажешься, если ты к ним подходил.
Часто клиент - может быть тонким в трехзвенке - дешевле среднего в 2-звенке.
Перерасперделение аппаратных ресурсов между серверами, если трех звенка аппаратная. (Т.е. если WEB сервер и сервер БД на одном компе - это тоже пример трехзвенки, но программной)
Вынесение тяжелого, но не свойственного СУБД функционала на средний уровень.
Многие де факто пользуются так или иначе трехзвенкой, используют, например, WEB сервера, но считают это двухзвенкой. Не знаю почему.
Однако, все это все равно клиент-серверная технолгоия, скорее всего. Так как обработка запросов на сервере. Клиента на промежуточном (сервер приложений), промежуточного (он клиент для сервера БД) на серовере БД.
8 окт 04, 10:22    [1017964]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
savage79
Member

Откуда:
Сообщений: 27
vadiminfo

Вообще если клиенты только интерфейсом занимаются, то при исправлении функционала на среднем уровне опять клиентов исправлять не надо. У нас есть система отчетов (2-звенка) и система WEB (3-звенка Сервер БД, Web-сервер, клиенты) - отчетов.

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

vadiminfo

Вынесение тяжелого, но не свойственного СУБД функционала на средний уровень.

Все верно сказано. Поясню примером.
Система планирования загрузки обрудования для промышленности. Входными данными является техпроцес и БД оборудования, инструмента и присособлений предприятия. Сервер приложений для планирования использует сложные алгоритмы оптимизации и платнирование поизодства обычно идет по расписанию, т.е. этот процесс ресурсоемкий и требует порой значительного времени (например планирование может идти целую ночь).
Понятно что на клиенте это все посчитать сложновато, т.к. ресурсов клиента зачастую не хватит. На сервере БД тоже сложновато будет реализовывать алгоритмы оптимизации. Посему весь функционал переносим на сервер приложений.
Примерами могут служить еще поисковые системы. У них в БД хранятся необходимые индексы. А сама система предаствляет собой сервер приложений со множеством сервисов, которые могут анализировать содежимое множества типов и форматов документов.
Еще пример, системы проектного упраления, когда нужно по определенной очереди задач рассылать пользователям задания, выполнять оптимизацию загрузки ресурсов участвеющих во многих проектах.
8 окт 04, 11:10    [1018237]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
locky
>Ты эта запускать пробывал ? Работаить ?
А поглядеть (почитать) религия не позволяет?

Ты считаишь, что у всех пользавателей ИНета на компе должен MSSQL стаять?
8 окт 04, 11:10    [1018238]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

>>>Ты эта запускать пробывал ? Работаить ?
>>А поглядеть (почитать) религия не позволяет?

>Ты считаишь, что у всех пользавателей ИНета на компе должен MSSQL стаять?
Нет, я так не думаю. Но Вы так живо отреагировали, что я решил: Вы попробовали и у Вас не получилось.

Posted via ActualForum NNTP Server 1.0

8 окт 04, 11:34    [1018417]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
savage79

Более правильно называть трехзыенками системы с серверами приложений. Т.е.
СУБД - Сервер Приложений - Интерфейсы, где интерфейсы могут быть как WEB (в данном случае появляется еще 1звено-вебсервер), так и GUI.


Но можно говорить не о трехзвенках при сравнении с классической двух звенкой, а моногозвенках. Тогда можно сосредоточиться на кол-ве звеньев, абстрагируясь от их деталей. Например, это может быть удобнее при выявлении достоинств и недостатков, связанных именно с количеством звеньев. (В, конце концов, тогда можно будет рассматривать и многозвенки, в которых нет даже сервера БД).
Но классифицировать трехзвенки: одни с сервером приложений, другие с WEB - сервером. И сосредоточиться на их сравнении внутри трехзвенок. Такой подход тоже может иметь свои плюсы.
8 окт 04, 11:48    [1018511]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Да, все-же нужно отделять трехзвенки (многозвенки):
1. классические трехзвенки с явно выраженным апп-сервером, клиентом и БД, причем все звенья пишутся программером
2. так называемые трехзвенки на основе веб-сервера, которые являются по сути обычными двухзвенками: программируется только два звена, а броузер является всего лишь другим видом интерфейса - не ГУИ.

Так вот со вторыми проблем нет.
Есть с первыми.
И есть проблема - обсуждаемая тут, мне так кажется - звучащая так: лучше классической двухзвенки в 99% случаев в приложениях, нацеленных на клиент-серверную архитектуру в принципе, ничего не может быть. И трехзвенка даст только больше мороки, работы и обслуживания.

Хреново выразился, но надеюсь понятно. :)

Да, по поводу независимости от СУБД клиента, который ходит к апп-серверу: это только рекламный лозунг, все-равно придется переделывать или менять апп-сервер. Так какая разница тогда, если я с тем же успехом поменяю вызовы ХП у клиента? Никакой! Сам клиент - интерфейс - не меняется. Зато нет лишнего звена, которое сначала надо еще сделать, потом сделать клиента, который будет вызывать методы апп-сервера - это вместо того, чтобы вызывать ХП или запросы из БД.

Ну а объединение разных систем - да, тут может нужен апп-сервер, но зависит от структуры системы: что нужно получить, чтобы одновременно работать во всех системах или просто иметь необходимые данные из всех систем в своей. Во втором случае можно обойтись импортом данных (вот рубль в топике-близнеце не знал про импорт данных из разных систем в свою, его это сильно потрясло :)). В первом наверное этим не обойдесся :) Но как часто бывают такие задачи? Редко.

ЗЫ Никто же не против многозвенок в принципе. Только применение их должно быть по месту :)

-- Tygra's --
8 окт 04, 12:26    [1018698]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
savage79
Member

Откуда:
Сообщений: 27
tygra
И трехзвенка даст только больше мороки, работы и обслуживания.

Почему ты решил что трехзвенка добавит тебе мороки. Ты с ними работал? или тока предполагаешь? Морока для тех кто их не знает.
Обслуживание сервера приложений (AS - appserver) ничуть не отличается по сложности от обслуживания сервера БД. Только зачастую обслуживание сервера БД при наличие AS уже не требуется, т.к. все эти функции встроены в AS, центр администрирования смещается к AS.
8 окт 04, 12:51    [1018843]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
savage79
Почему ты решил что трехзвенка добавит тебе мороки. Ты с ними работал? или тока предполагаешь? Морока для тех кто их не знает.
Обслуживание сервера приложений (AS - appserver) ничуть не отличается по сложности от обслуживания сервера БД. Только зачастую обслуживание сервера БД при наличие AS уже не требуется, т.к. все эти функции встроены в AS, центр администрирования смещается к AS.

В понятие обслуживания входит изменение бизнес-логики из за изменения ТЗ. Вот тут то и есть морока для систем, где класс на классе сидит и классом погоняет. Можно как угодно хорошо спроектировать и написать иерархию классов, но все равно копаться в коде ООП не самое интересное занятие. Я думаю все это происходит из за того, что 3-и звенья пытаются обвязать РСУБД обьектным описанием сущностей, что взаимоисключающие понятия. Тут в данном случае даже Cache лучше выглядит, так как ООП просто ложится в его парадигму хранения и обработки данных. У меня лично всегда, когда я вижу связку, где РСУБД хранилище данных, а основные описания структуры и логики реализованны на ООП возникает видение ежа с удавом.
8 окт 04, 13:23    [1019042]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Обслуживание сервера приложений (AS - appserver) ничуть не отличается по сложности от обслуживания сервера БД. Только зачастую обслуживание сервера БД при наличие AS уже не требуется, т.к. все эти функции встроены в AS, центр администрирования смещается к AS


Сие наводит на мысль, что у вас в СУБД лежат только таблицы и больше ничего. А зачем тогда СУБД нужна вообще?
Был недавно не менее "прохладный" топик по поводу использования select-ов прямо из клиента (апп-сервера в этом случае) вместо ХП в БД. Очень уж это странно.
И уж намного проще поменять ХП, чем менять код классов в апп-сервере (а потом его компилять, выкладывать .....).
Ну а про администрирование вообще умолчу - или промышленный сервер, или самописная вещь.

-- Tygra's --
8 окт 04, 13:31    [1019086]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
tygra

Родной, тебе не надоело? Просто интересно, как ты думаешь, что такое appserver - т.е. какие функции он берет на себя?
8 окт 04, 14:05    [1019287]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Да надоело уже, да что ж с вами сделаешь

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

Иначе я даже и не знаю - каков смысл?

А по вашему - что такое апп-сервер?

-- Tygra's --
8 окт 04, 14:25    [1019396]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Tygra так нечестно - хоть бы глянул одним глазом - что же это за звери такие appserver'а. Для такого бывалого appserver-ненавистника не знать что же такое appserver как-то не солидно

В общем! уважаемые нелюбители "трех-звенок" - не позорьтесь - прочтите хоть раз что такое application server
Tomcat
Sybase EAServer

Если коротко - то это приложение являющееся контейнером компонентов* и предоставляющее для них
- единую систему контроля ресурсов*
- систему управления кластеризацией
- систему управления распределением нагрузки
- систему управления жизненным циклом (создание/удаление/организация пулов и кэшей)
- систему управления развертыванием
- систему разграничения и контроля доступом
- систему для единого администрирования
- и т.д.

При этом под компонентами, в зависимости от платформы, понимается достаточно разные вещи - от servlets/eb в java до com+ компонентов в MS MTS
А под ресурсами - вообще много чего (от транзакций/соединения с БД и т.д.)

Так вот - нетрудно заметить, что к размещению бизнес логики app server'а имеют лишь косвенное отношение

А теперь ответьте на вопрос, tygra и Co, неужели ничего из перечисленного вы никогда не пытались сами добавить в свои приложения?! Неужели все это не интересно и лишено смысла? Так вот - все это уже есть и притом готовое - просто надо выучить и использовать!
PS> я думаю что все эти войны “2х звенщиков” с “много-звенщиками” это просто недостаток IT образования в нашей стране. У нас принято больше полагаться на "гениальность" а не на опыт других людей. Мы не любим использовать то что сделали не мы - обязательно все хочется написать самим. Поэтому у нас и не приживаются ни java ни какие либо другие технологии в которых необходимо вначале очень долго учиться у других - и лишь затем применять. Т.е. здесь не прокатывает вариант "на коленках"
8 окт 04, 15:02    [1019559]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Во, это уже дело, а то пожар один.... Давайте вместе разбираться, а то может зря все, тушить надо.

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

Щас попробую, но я только за себя могу, с остальными так же как и вы только по форуму коллега (пока еще), вместе не работаем.

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

автор
Если коротко - то это приложение являющееся контейнером компонентов* и предоставляющее для них
- единую систему контроля ресурсов*

Соединения с БД - что именно тут контролировать?
Транзакции - с клиента никогда не применяем, только внутри ХП.
Каких еще ресурсов? Пока это не узнаю, не могу скзать больше ничего...

автор
- систему управления кластеризацией

Ну кластеризация.... Если это то, что я думаю, то: В Оракле есть понятие кластера, так что там все и так путем. В MS SQL конечно нет таких кластеров, но в принципе можно и тут сделать. Хотя пока что не понадобилось. А если так сильно понадобится - тогда Оракл.

автор
- систему управления распределением нагрузки

Смотря что под этим понимать. Можно кластера понимать под этим. А можно и network load ballansing сверху повесить и пусть распределяет. У нас так веб работает. Хорошая вещь.
Но опять же - нужно ли это когда? И нужно ли это для апп-сервера или для БД?

автор
- систему управления жизненным циклом (создание/удаление/организация пулов и кэшей)

Я так понимаю, это относится именно к апп-серверу. А если его нет - нет и вопроса. Или это что-то, имеющееся в двухзвенке?

автор
- систему управления развертыванием

Это объясните мне, что это такое. Много на что можно подумать.

автор
- систему разграничения и контроля доступом

Дык... Есть встроенная система прав и доступа у MS SQL, да и у любой СУБД. Есть еще своя система для разграничения доступа к действиям на клиенте. Вот. Зачем мне какая-то другая, на апп-сервере?

автор
- систему для единого администрирования

Надо все же расширять понятия: что такое "единое админимстрирование"? Для администрирования СУБД есть свои встроенные средства, как графические так и процедурные. Для администрирования клиента...??? А что там можно администрировать. Только права. Это выше.

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

автор
Так вот - нетрудно заметить, что к размещению бизнес логики app server'а имеют лишь косвенное отношение

Вот то-то и оно: где она, бизнес-логика, лежит все-же, в БД или апп-сервер, и если в БД, тем более зачем же апп-сервер тогда нужен, вот этого то я не пойму!
Потому как получается, что мне в двухзвенке ничего такого не нужно - из всего перечисленного у нас либо оно уже есть - само по себе или сделанное, или его у нас нет и не нужно. Вот и получается, что двухзвенка идеально подходит для решения к-с задач.


-- Tygra's --
8 окт 04, 15:36    [1019728]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
savage79
Member

Откуда:
Сообщений: 27
ASCRUS

В понятие обслуживания входит изменение бизнес-логики из за изменения ТЗ. Вот тут то и есть морока для систем, где класс на классе сидит и классом погоняет. Можно как угодно хорошо спроектировать и написать иерархию классов, но все равно копаться в коде ООП не самое интересное занятие. Я думаю все это происходит из за того, что 3-и звенья пытаются обвязать РСУБД обьектным описанием сущностей, что взаимоисключающие понятия. Тут в данном случае даже Cache лучше выглядит, так как ООП просто ложится в его парадигму хранения и обработки данных. У меня лично всегда, когда я вижу связку, где РСУБД хранилище данных, а основные описания структуры и логики реализованны на ООП возникает видение ежа с удавом.

Если для тебе проще реализовывать системы планирования, потимизации и пр., примеры которых я привел выше, на хранимых процедурах - то вперед.
Повторюсь "Система планирования загрузки обрудования для промышленности. Входными данными является техпроцес и БД оборудования, инструмента и присособлений предприятия. Сервер приложений для планирования использует сложные алгоритмы оптимизации и платнирование поизодства обычно идет по расписанию, т.е. этот процесс ресурсоемкий и требует порой значительного времени (например планирование может идти целую ночь)." это проще сделать на ХП или на нормальном языке программирования????! Чтож вы про эти системы все умалчиваете???? а начинаете сваливать на всякую фигню типа "ой, сложности администирования и пр..". В вашем понятии система заключается только в том, как данные в БД записать, и потом оттуда их получить. А пораскинуть мозгами и представить что существует большой класс сложных систем вы уже не можете.

funikovyuri

В общем! уважаемые нелюбители "трех-звенок" - не позорьтесь - прочтите хоть раз что такое application server
Tomcat
Sybase EAServer

Если коротко - то это приложение являющееся контейнером компонентов* и предоставляющее для них
- единую систему контроля ресурсов*
- систему управления кластеризацией
- систему управления распределением нагрузки
- систему управления жизненным циклом (создание/удаление/организация пулов и кэшей)
- систему управления развертыванием
- систему разграничения и контроля доступом
- систему для единого администрирования
- и т.д.

При этом под компонентами, в зависимости от платформы, понимается достаточно разные вещи - от servlets/eb в java до com+ компонентов в MS MTS
А под ресурсами - вообще много чего (от транзакций/соединения с БД и т.д.)

Так вот - нетрудно заметить, что к размещению бизнес логики app server'а имеют лишь косвенное отношение


В общем все верно сказано!, только Томкат позицируется скорее как Servlet & JSP контейнер, а вот сервер по спецификации J2EE это уже настоящий сервер приложений (BEA WebLogic, Sun One Application Server, Borland Application Server, Oracle Application Server и пр...). Хотя к слову сказать, RMI сервер тоже можно назвать сервером приложений.
8 окт 04, 15:40    [1019751]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Добавлю свой ответ из параллельного топика:

tygra
Ну так об том и речь (то, о чем речь :). Где двухзвенка подходит - там и есть. Где сделать на двухзвенке намного хуже, чем на многозвенке, и многозвенка дает реальный выигрыш - нет проблем, кто же спорит!

Но когда говорится что-то типа: двухзвенка это прошлое, надо все делать на многозвенке; логика вся должна быть в апп-сервере и никогда не в СУБД ... и т.д. - ну это же бред, против этого и шумим :)

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


Мы не бандиты, мы благородные пираты :)

-- Tygra's --
8 окт 04, 15:42    [1019762]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
2 savage79

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

Или как оно у вас?
Я точно не пойму, как работает ваша система - что там делают пользователи, что делает апп-сервер, что именно есть "процес планирования производства".

Потому что со стороны по вашему определению складывается ощущение, что апп-сервер нужен для того, чтобы запустить один процесс.
Уж извините, не планировал производств. :)

-- Tygra's --
8 окт 04, 15:50    [1019813]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
savage79
Member

Откуда:
Сообщений: 27
tygra
2 savage79

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

Или как оно у вас?
Я точно не пойму, как работает ваша система - что там делают пользователи, что делает апп-сервер, что именно есть "процес планирования производства".

Потому что со стороны по вашему определению складывается ощущение, что апп-сервер нужен для того, чтобы запустить один процесс.
Уж извините, не планировал производств. :)

-- Tygra's --

почитай книжки
8 окт 04, 15:59    [1019861]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Если для тебе проще реализовывать системы планирования, потимизации и пр., примеры которых я привел выше, на хранимых процедурах - то вперед.
Повторюсь "Система планирования загрузки обрудования для промышленности. Входными данными является техпроцес и БД оборудования, инструмента и присособлений предприятия. Сервер приложений для планирования использует сложные алгоритмы оптимизации и платнирование поизодства обычно идет по расписанию, т.е. этот процесс ресурсоемкий и требует порой значительного времени (например планирование может идти целую ночь)." это проще сделать на ХП или на нормальном языке программирования????! Чтож вы про эти системы все умалчиваете???? а начинаете сваливать на всякую фигню типа "ой, сложности администирования и пр..". В вашем понятии система заключается только в том, как данные в БД записать, и потом оттуда их получить. А пораскинуть мозгами и представить что существует большой класс сложных систем вы уже не можете.

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

Теперь рассмотрим случай тяжелых алгоритмов, которые явно сложно впишутся в SQL. Естественно они в СУБД не нужны, но относятся ли они к области обработки и хранения данных ? Ни в коем разе. Вот Вы считаете свое планирование, а потом готовые результаты заносите в БД - именно это и есть входящая информация для БД, с которой в ней начинается работа. А расчет - это есть ни что иное, как просто отдельный уровень, отвечающий за сложные алгоритмические действия, и где его реализовывать, это уже вопрос проектировщика. Хотите, реализуйте на клиенте, хотите вынесите COM-сервером и пусть клиент к нему обращается. Если позволяет СУБД, накатайте расчеты на Java или Си, подрубите к БД как расширенные ХП и вызывайте их прямо с SQL. Но к-с система то все равно остается 2-х звенной, не имеет расчетный модуль отношения никакого к взаимоотношениям клиента и сервера и не должен иметь. Думаю Вы знаете, что при программировании правилом хорошего тона является разделять задачу на автономные независимые подзадачи ? Так почему же Вы пытаетесь из за только одного расчета все однотипно запихнуть в сервер аппликаций, беря за планку критерия выбора хранения логики самую сложную - не легче ли для каждой задачи пользоваться предназначенными для этого средствами ? Для обработки информации лучше всего подходит SQL и проектирование логики на ХП и триггерах, для расчетов алгоритмические языки, для интерфейсной части любое RAD средство - так и пользуйтесь по максимуму возможностями каждого, а не пытайтесь выбрать одно и все на него лепить. Как говорится, разделяй и властвуй :)
8 окт 04, 16:08    [1019913]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
2 ASCRUS
Правильно сказал!!! На все сто!

Так что, savage79 , читай книжки ты.
В том числе и правила хорошего тона, переиздание 2004 года прочти, поможет :)


-- Tygra's --
8 окт 04, 16:18    [1019965]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
savage79
Member

Откуда:
Сообщений: 27
tygra
В том числе и правила хорошего тона, переиздание 2004 года прочти, поможет :)

причем тут хороший тон? а вроде хамством не занимался
8 окт 04, 16:30    [1020035]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8 9 10 .. 17   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить