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

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

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

Дальнейшее непонятно, в чью сторону, но сделаем в сторону СУБД :)

автор
маштабирование - явно апп сервер предоставляет больше возможностей.

Никак не видно, чтобы это было так.

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

А что, вы в СУБД секьюрити не видели? А зря, оно там есть, уже готовое. А про возможности это зря - из Excel например сможете к апп-серверу приконнектиться?

автор
мощнее язык - java vs t-sql (не забывем что sql никто не отменял, речь о процедурных расширениях) спецы дешевле, кода меньше, выбор больше. на все задачи уже есть патерны и фреймворки.

Смотря про какую мощность говорить, пока и SQL хватает. Для дифференциальных уравнений есть расширенные процедуры - цепляйте DLL и вперед.
А вот по поводу спецов... Это вы зря, спецов СУБД гораздо больше, чем многозвенных....
автор
хотя конечно можно java вызывать из t-sql но смысла от этого маловато.

Ну почему java? На что она вам далась то? Я лично на java не пишу - и ничего.

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

Что, уже и программировать не надо? А если "изобретение" мне не подходит - как 1С, вроде все в ней есть, а все-равно под себя подгоняют и подгоняют. Только выходит плохо.

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

Эт точно!

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

Откуда:
Сообщений: 27
Yo!
есть все один небольшой минус :) он работает не эфективно и делает кучу бесполезных действий ...

Есть такое дело, за все удобства нужно платать.
В основном при этом не эффективно работает persistence manager, который отвечает за отображение объектов ОО-языка на таблицы БД. Но такие менеджеры всячески улучшают и оптимизируют.
Хотя говорить что это работает неффективно не совсем правильно, так же как говорить что работает не эффективно и делает кучу лишних действий высокоуровневый язык программирования, ведь ассемблер эффективней )
11 окт 04, 16:45    [1024361]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

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

Я против выноса логики в апп-сервер!!!

Не должно ее там быть. И почему-то вы все говорите про какую-то логику клиента. Да нет никакой логики клиента - есть логика системы. Если лично вы хотите положить ее в клиента - ваше право, только это не есть гут. Я же предпочитаю внести всю логику в БД.

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

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

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

А вот надстройка над СУБД - это уже апп-сервер, среднее звено.

-- Tygra's --
11 окт 04, 16:48    [1024369]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Yo!
Guest
2tygra

полочи :) может за умного сойдешь ...
и почитай на досуге куда уже сейчас двигается MS и его MS office.
11 окт 04, 16:52    [1024391]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
savage79
Member

Откуда:
Сообщений: 27
tygra
сейчас много откуда можно работать с СУБД, в отличие от работы с апп-сервером, которого просто так не увидишь (из Excel например).

кто тебе такую глупость сказал????
подключайся к апп-серверу откуда хочешь и как хочешь, хоть из excel и word.обычно у апп-сервера есть куча интерфейсов для такие подключений, начиная от RPC и RMI, заканчивая SOAP. Многие системы эл.документооборота используют офисные системы для формирования и последующей сдачи таких документов из word-а, например, в систему документооборота для хранения. Для такой работы у ms office есть VBA, с помощью которого можно подключать любые COM объекты (такие как MSSOAP )и выполнять любые над ними действия.
11 окт 04, 16:54    [1024404]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

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

Или еще куда? Ну так скажи. Чего все время загадками говорить?
А знаешь куда Оракл двигается? Аааа, а я не скажу :) Я типа умный :)

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

Откуда:
Сообщений: 27
tygra
Я против выноса логики в апп-сервер!!!

Это твое личное мнение, и если производители апп-серверов (SUN, Oracle, BEA, Borland) тебя послушают при этом, напиши об этом нам обязательно )
11 окт 04, 16:57    [1024422]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

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

Хорошо, квиты :)

Но я все-равно не могу понять: для чего мне писать еще один (два,три,..?) звена в системе, где я обойдусь двумя?
Там, где я не обойдусь - это понятно, таких применений мало, но они есть. А вот там, где обойдусь - где смысл в апп-сервере? Если я сделаю систему, потратив N времени и сил, зачем мне еще тратить N+N/3 времени и сил на то же самое?

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

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

Но я все-равно не могу понять: для чего мне писать еще один (два,три,..?) звена в системе, где я обойдусь двумя?
Там, где я не обойдусь - это понятно, таких применений мало, но они есть. А вот там, где обойдусь - где смысл в апп-сервере? Если я сделаю систему, потратив N времени и сил, зачем мне еще тратить N+N/3 времени и сил на то же самое?

Писать бизнес логику на сервере приложений ничуть не сложенее чем на ХП. Сил при этом ты потратишь равно столько же, ни на йоту больше, а может даже меньше, т.к. как уже было сказано выше есть куча готовых решений для этого, типа всяких там шаблонов и пр... Ну а для чего нужен апп-сервер мы уже писали выше.
11 окт 04, 17:05    [1024453]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

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

Не я один - тут таких много, кто против выноса логики оттуда, где ей место.

А продуктов разных много, смысла на них опираться нет. Потому как есть еще понятие моды - даже тут, в ИТ. Ну модно использовать апп-сервера. Ну что поделать. Вот было - и может есть - модно писать сайты на java. Только то, что это полная ж... никто же не говорил. Просто - java рулез и все. А то, что на asp.net делается все это в десять раз проще и быстрее.... Хотя .net теперь тоже модная вещь. :)

А вот есть C-Builder, Delphi, J-Builder... еще всякого. Это же не значит, что например на C-Builder нужно обязательно писать, потому что его выпускают.

Так что тут.......

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

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

Я против выноса логики в апп-сервер!!!

Я же предпочитаю внести всю логику в БД.



Это яснее. Так как второе тоже можно считать трехзвенкой. Точнее есть ее признак - основная логика приложения на сервере. Это и сбивало с толку при выяснении преимуществ трехзвенок над двузвенками.


автор

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

Ну, разумеется есть преимущества хранении логики в БД, если эта логика там себя хорошо чувствует. Есть даже преимущества от храннения там и интерфейсов с пользователем.
Многие преимущества, что я приводил тогда, конечно, можно не рассматривать, так как они обусловлены тем, что логика на сервере, не важно каком: сервере приложения или сервере БД.
Тогда кол-во преимуществ уменьшается. Но все же.
Разделение задачи на части по функционалу может упростить ее решение.
Функционал приложений (а их может быть много разных к одной БД) может быть достаточно сложным и, в общем случае, может быть плюс даже от того, что сами сервера на разных аппаратных плптформах или по разному настроенных серверах. Так специфика обработки данных и вычислений может требовать различных ресурсов или различного управления ими ОС.
Разделение труда. Управление БД и разработка логики приложения в общем случае требуют разных знаний.
Существуют технологии типа EJB, WEB - сервисы существенно упрощающие разработку и поддержку корпаративных систем. Они не всегда уместны в БД.
Это первое что напрашивается само собой.
11 окт 04, 17:35    [1024603]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
funikovyuri
Member

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

1. Все пришли к выводу, что на клиенте бизнес-логику хранить не хорошо (и слава богу). Клиентское приложение должно красиво рисовать рюшечки, гриды, отчеты и вообще вести простой и безоблачный образ жизни :)

Рисование формочек на самом деле тоже будет зависеть от бизнес логики. Так что это только в относительно простом проекте моно рисовать gui без оглядки на все остальное!

На самом деле это просто вопрос организации. Вот интересно ASCRUS, что у тебя представляет собой клиент. Ну т.е. есть же какие-то правила, какая-то организация кода и на клиенте? Какая?
11 окт 04, 17:51    [1024658]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
funikovyuri
ASCRUS

1. Все пришли к выводу, что на клиенте бизнес-логику хранить не хорошо (и слава богу). Клиентское приложение должно красиво рисовать рюшечки, гриды, отчеты и вообще вести простой и безоблачный образ жизни :)

Рисование формочек на самом деле тоже будет зависеть от бизнес логики. Так что это только в относительно простом проекте моно рисовать gui без оглядки на все остальное!

На самом деле это просто вопрос организации. Вот интересно ASCRUS, что у тебя представляет собой клиент. Ну т.е. есть же какие-то правила, какая-то организация кода и на клиенте? Какая?

Гм, ну у меня же клиент на PowerBuilder :) Там все просто и надежно - управление интерфейсом реализовано на основе ООП через повторно наследуемые компоненты и формы. Отображение данных сделано на представлениях DataWindow, задача которых получить данные с БД через ХП, отобразить их и записать изменения обратно через ХП. Так как DataWindow это не код, а именно представление, в котором есть собственный язык выражений DataWindow Expression (по аналогу как у Crystal Report), то все отображение с бизнес-логикой и отрисовывается прямо в DataWindow (что то типа "Column2.Visible = IF(Column1 = 1, 1, 0)" и т.д.). Проверки и ограничения на значения полей в том же DataWindow и описываются. Естественно все в DataWindow описывать на языке выражений нельзя, поэтому на пересечении унаследованных от базовых форм и компонент и лежащих на них DataWindow Control (визуальный компонент, оживляющий представление DataWindow) и могут быть дополнительные участки кода. Однако с учетом того, что представление DataWindow можно динамически (в том числе и выражения) менять прямо из кода, плюс прямо в язык PB встроена поддержка SQL операторов, то особых сложностей при программирование клиента не наблюдается. У меня есть прекрасно отработанный компонент построения визардов, всю сложную логику ввода и изменения данных я делаю через него, главное преимущество, что нет проблем с вводом данных один-ко-многим, заносим все через визард, нажимаем "Готово", визард автоматом стартует транзакцию и с каждой странички визарда по очереди их DataWindow начинают себя сохранять согласно своим установкам, реагируя на событие странички "Сохранись". Дошли до конца без проблем, визард делает COMMIT. Где то по пути возникла ошибка, ROLLBACK, переход на сбойную страничку и модальное окно с 2 вкладочками сообщений об ошибке - одно для юзеров (с переводом ошибки на понятный язык), второе для меня лично - с полными параметрами вызова ХП, SQLState и SQLCode, а так же полным трайсом последовательности вызова от начала ХП до сбойного места (например, если ошибку триггер сгенерил). Флаги изменения записей у DataWindow не сбрасываются на удачное сохранение, так что пользователь с одной стороны после возникновения ошибки ничего еще в БД не записал, с другой стороны исправив ошибку он еще раз сможет заново попробовать повторить запись в БД. Естественно ошибки логируются, так же для особо нервных пользователей есть кнопочка лично послать мне по мылу. Если же смотреть на самого клиента, то логика в нем чисто интерфейсная - да, я могу согласно логике запрещать/разрешать редактировать какие то поля, даже проверять вводимые значения, если это не напряжно, но все равно последняя инстанция - это БД и триггера, что кстати неплохо контролирует моих кодо-писателей, которые любят сначала писать, потом проверять, а левые данные в БД никому особо не нужны :) Более сложные действия хранятся только в СУБД - например у меня на PB есть компонент организации выбора по фильтру. Так вот он абсолютно ничего не делает - в БД есть таблички со схемами фильтров и запросов, задача этого компонента построить удобоваримый интерфейс для клиента, ориентируясь по описаниям разрезов фильтра (вплоть до организации выбора lookup-полей через список с чекбоксами). Все что юзер в этом компоненте выбирает, PB честно пишет в специальную глобальную временную таблицу. Далее когда все что можно выбрано ... PB запускает ХП на WatcomSQL, которая сама шерстит времянку, строит запрос, соединяя все подзапросы, условия и т.д. и через динамический SQL возвращает id найденных обьектов. В итоге оба молодцы - PB красиво строит интерфейсы, ASA выполняют всю работу по организации работы с данными. Вся прелесть в том, что оба средства позволяют строить динамический интрепретируемый язык - WatcomSQL на стороне сервера, DataWindow на стороне клиенте. Но большая заслуга ASA - это ее оптимизатор, который разворачивает построенный для фильтра довольно большой и по любому неуклюжий запрос, который состоит из кучи соединенных подзапросов в красивый план так, как будто бы он ручками был написан лично мною. Плюс здорово пригождаются всякие фичи типа KEY JOIN (автоматическое соединение по внешним ключам), INSERT ... ON EXISTING SKIP|UPDATE|ERROR (по ключу таблицы), функция LIST (аггрегатная функция сложения в текст) и т.д., что позволяет в нужные моменты генерировать запросы, не сильно напрягаясь с получением метаструктуру и генерации скриптов для различных задач.

То же самое и касается моей технологии построения по шаблонам и макросам - на PB сейчас реализованы DataWindow, позволяющие легко дописывать в публичную библиотеку макросов новые макросы, расставлять дополнительные аттрибуты по таблицам и полям, и т.д. Компиляция же шаблона в готовую ХП, которая уже и будет генерить нужную информацию занимаются всего 12 ХП на WatcomSQL, причем без разницы что генерить по шаблону - скрипт на SQL, HTML, XML, файл с разделителями или текстовый отчет - есть типовые шаблоны, в них есть секции, в том числе и вложенные, есть автоматическая поддержка организации цикла для указанного запроса по секции, есть локальные переменные и область их видимости в секциях, есть возможность управлением генерации контента посредством WatcomSQL прямо внутри шаблона (аналог ASP), есть поддержка макросов, позволяющих описывать и повторно наследовать язык хранимых процедур и конструкции языка запросов (я очень долго думал, как до этого можно дойти, не один год) для диалекта шаблона SQL или описывать расширения или новые тэги для того же диалекта HTML. Сейчас я вот потихоньку неспеша подумываю ввести в поддержку своего генератора по шаблоном нового диалекта - DataWindow expression, в принципе текстовое представление DataWindow очень смахивает на XML, да и описания на XML новый PB воспринимает, было бы неплохо, если бы WatcomSQL не только скрипты или HTML генерил, но и мог автоматом в БД выстраивать и в дальнейшем синхронизировать представления DataWindow, ничего сложного в этом особо не вижу, это только вопрос времени и необходимости, сначала нужно повертеть все в разные стороны и прикинуть, а стоит ли такая овчинка выделки, это ведь придется дальше расширять свою поддержку метаструктуры уже на уровне колонок таблиц, представлений и ХП, плюс рисовать собственный дизайнер DataWindow, который благодаря широким возможностям PB делается то элементарно (у компонент PB есть поддержка в рунтайм таких свойств, как Resize, Move, Title и т.д., так что дизайнер форм или DataWindow - это не проблема), но пока это для моего проекта не актуально и вроде пока DataWindow и ручками через родной дизайнер рисуются неплохо :)
11 окт 04, 21:22    [1025019]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

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

Все пришли к выводу, что на клиенте бизнес-логику хранить не хорошо (и слава богу). Клиентское приложение должно красиво рисовать рюшечки, гриды, отчеты и вообще вести простой и безоблачный образ жизни :)

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

ASCRUS

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


Ее отдельные ф-ии лучше писать на средствах наиболле пригодных для реализации во всех отношениях. Ясно, что на Дельфи некоторые клиентские вещи лучше реализуемы, чем на ХП. А для чего, а для некоторых задач, связанных с данными лучше ХП.

Т.е. не совсем так. Ведь это не вопрос голосования я надеюсь. Кроме того, не ясно, что этих трех достаточно для вопроса об использовании сервер приложения. Еще имею значение другие аспекты. Что лучше подходит для сложной системы: выполнять сложную логику на сервере БД или специализированном сервере? Даже в случае сотен тысяч пользователей, возможно, перед сервером БД еще один сервак поставить нужно. Т.е. еще нужно быть уверенными, что этих трех достаточно.



ASCRUS

- использование встроенного языка хранимых процедур СУБД позволяет в полном обьеме, достаточно легко и полнофункционально реализовать все, что перечесленно в этих 3-х пунктах


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


ASCRUS

Способ создания слоя бизнес-логики № 2
- использование апп-сервера и высокоуровнего ООП языка.


Высокоуровневый ООП язык не помешает и в первом способе создания бизнес логики. Если не в БД, то на клиенте. Будь он в БД, может больше ф-ий логики приложения перешло бы в БД.


ASCRUS

Из этого вопроса возникает следствие - все мы программируем как минимум на 3-х звеньях, отделяя данные, бизнес-логику и клиента. Только одним нравиться это делать по SQL-ному, так как если посмотреть триггера и ХП, то окажется, что там от алгоритмического языка маловато будет - все запросы, да запросы. А другим нравиться все на классах, контейнерах и компонентах делать. Из сего вывод - сравнивать 2-х и 3-х звенку в данном контексте бестолку, давайте уж сравнивать подходы - алгоритмически-запросные и ООП-компонентные.





Можно и так сказать. Но есть и другие варианты. Кто-то в виде проектировщика пытается найти оптимальное решение и не только техническое, но и финансовое. А возможно и экономическое, т.е. заранее планирует дальнейшее развитие проекта. И тут дай ему Бог помощи не ошибиться с выбором арихитектуры.

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

Вообще-то ООП относится к алгоритмическим в целом пока еще. Может в ООМД появился непроцедурный ODL. И врядли ООП будет плохо дополнять ХП.
То что там много запросов, так на то он и язык БД, чтобы с данными работать и на то успешность РМД, чтобы так все и было. ХП в основном для поддержки его.
11 окт 04, 21:22    [1025020]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
Многие из тех кто написал в этот топик почему-то противопоставляют многозвенку и использование ХП. Я программирую многозвенки, но при этом всегда размещаю обработку на том звене где это лучше и проще всего сделать. Если я вижу что проще сделать на ХП и это не противочерчит общему подходу - буду делать на ХП. Иногда встречаются такие программы, архитекторы которых явно ничего не понимают в многозвенках или это их первый опыт - вроде и многозвенка, и вроде все правильно реализовано, но тормозит жутко. Встречал систему, многозвенку, которая любой отчет считала несколько часов, да и вообще медленно работала, из-за очень нерационального использования ресурсов. После улучшения архитектуры стала считать отчеты за секунды. Вот только улучшение архитектуры и изменение программы заняло около полугода при 20 разработчиках. При создании многозвенок цена ошибок заметно выше чем для клиент-сервера.
Про независимость от СУБД - такие требования даже к системам с многозвенкой предьявляются нечасто, обычно можно использовать все возможности СУБД.
На мой взгляд использовать многозвенки имеет смысл в первую очередь там где есть сложная бизнес-логика. На клиент-сервере, из моего опыта, тоже самое просто сложнее реализовать - многие функциональности по отдельности проще сделать на клиент-сервере, но вот чтобы это еще работало - проще сделать на многозвенке.
11 окт 04, 21:48    [1025036]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Вообще-то ООП относится к алгоритмическим в целом пока еще. Может в ООМД появился непроцедурный ODL. И врядли ООП будет плохо дополнять ХП.
То что там много запросов, так на то он и язык БД, чтобы с данными работать и на то успешность РМД, чтобы так все и было. ХП в основном для поддержки его.

Никто и не против, чтобы для ООМД появился эквивалентный SQL стандарт языка запросов. Наоборот все были бы только за - описывать структуру на классах со всеми вытекающими наворотами ООП гораздо легче и ближе к предметной области, чем физическую модель РСУБД. Дело за малым - должен быть язык для организации DML и DDL, он должен быть интрепретируемым. И главное - нужно иметь эффективный и надежный формат хранения данных, поддержку индексов, транзакционную модель, уровни изоляций и достаточно продвинутый оптимизатор выполнения запросов. Сейчас насколько я понимаю из за более простой и четко структуированной модели хранения данных, РСУБД имеют больше резервов для эволюции в данных направлениях по сравнению с тем же Cache и мне думается что деревья не самый лучший, хотя и наиболее легкий с точки зрения реализации, формат для хранения данных. Ну а современные сервера приложений в моих глазах - это ООП надстройка над РСУБД (может быть я где то и ошибаюсь, но по моему так оно и есть).

IMHO как только ООМД дорастет до собственного привлекательного хранения и обработки данных, тогда и можно будет задумываться о будующем РСУБД. Я лично, как любитель делания всяких интрепретаторов, макрогенераторов и препроцессоров с интересом поглядываю за развитием интрепретируемых ООП языков и тот же Питон для меня имеет довольно много интересных моментов в своем развитии, чем та же Java или C#, у которых и так все понятно :)
11 окт 04, 23:31    [1025064]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

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

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



Для меня вопрос о о моделях данных очень важен - так как резкая смена означет необходимость переучиваться. Фактически на сегодняшний день это могут быть: останется РСУБД, либо придет одна из ОРСУБД и ООСУБД, либо они как-то поделят рынок. Думаю, что есть тенденция РСУБД расширения в сторону ОРСУБД, судя по крупнейшим производителям. Если бы ООСУБД побеждала, крупнейшие производители РСУБД переметнулись или создали ООСУБД в параллель. Этого пока не произошло. Cache в качестве ООСУБД даже не всегда упоминается в толстых книгах, а сдругой стороны его сторонники говорят, что кроме ОО он еще и иерархический и даже реляционный и многомерный (что-то похоже на OLAP). В некоторых толстых книгах пишут о крахе идеи ООСУБД (в основном потому, что крупные производители не переметнулись как ожидалось), в других более осторожные оценки.
У крупнейших производителей есть какие-то шаги в сторону универсализма - собрать все хорошее от разных моделей. Конечно, у РСУБД есть много хорошего, поэтому полностью его, наверное, долго не устранят. И область применения, где ее недостатки мало проявляются - Бизнес приложения. А это существенно. Но все же пока будущее моделей не ясно. Однако, ООП, наверное, так или иначе будет прокладывать себе дорогу. А что еще? Вроде ничего другого пока в этом духе не видно на горизонте. Надеюсь, в ОРСУБД.



ASCRUS

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

Ну, вроде для РСУБД сервер приложений должен иметь не большее значение, чем клиент в плане ООП. Возможно, раз уж есть сервер приложений, то внешнюю модель данных они вынесли в объектной модели более четко. Если у нас часть модели в БД, а там ХП с процедурной парадигмой, то эта модель не очень просматривается. Но если традиционная двухзвенка, то на клиенте можеет быть тоже ООП, и наваяна объектная внешняя модель. Ну может Вы и правы. Но нужно уточнить термин надстройка. Вообще интересная мысль, я не обращал раньше на это внимание.
12 окт 04, 01:19    [1025098]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
1. В этом топике много наезжали на тригера + говорили что они перестанут существовать, что их сложно писать, что блин "кода пишут тригера монитор темнеет :))" --- по этому поводу могу сказать одно - тригера (в MS SQL) очень легки в написании (кто писать неумеет ему и простой Select сложен), удобны в применении, и позволяют обеспечить целостность данных разных табл. а также многое другое. Да кстати не то что тригера вырождаются = а даже наоборот скоро и в MySql появятся триггера.
2. ADO - писал(пишу) на Delphi приложения для больших БД = нареканий ни каких не имею, хотя могу тоже самое делать и через ODBC ---- может кто в состоянии объяснить чем плохи эти 2е технологии (не так что блин они там чтото пользуют и вощем тормозят по умолчанию - а подробно теория + примеры личной жизни).
3. MS SQL позволяет получить доступ к БД на низком уровне - это верно... Сам не делал, но друг писал веб интерфейс для какойто канторы у которой база на MS SQL и сам писал под этот интерфейс провайдера...
4. Переносимость = да работает ток под виндой и при чем полную версию MS SQL на профессионал непоставить = но ведь всетаки большинство серьезных контор всетаки работает с виндой!!! Вообще НЕ задавался таким вопросом - тобишь если писал под MS SQL на нем и работало.... Хотя экспорт возможен даже в эксель таблицы...
5. Транзакции - многоли SQL серверов имеют понятие транзакций - или может это тоже абсолютная глупость?
6. Работа с распределенными БД - Репликации - на последнем семинаре по MS SQL который прошел в Москве (вобщемто этот доклад зачитывался много раз) был зачитан доклад посвещенный репликациям = и в том числе было сказано что начиная с MS SQL 2005 репликации будут работать практически без недостатков. Нужныли репликации али нет судите сами.
7. Сравните удобство скажем MS SQL и любой др системы например Oracle. И аналоги EM в других СУБД. И не станем забывать о требовательности Oracle к оперативной памяти.....


Хотелось увидеть грамотный отзыв на этот мой пост..... И перебор систем которым это под силу = а потом подсчитаем количество таких СУБД :))
20 окт 04, 14:43    [1048546]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
да кстати для решения задачи укрытия данных от конечных пользователей есть представления, с которыми пользователи работают как с таблицами... Зачем для этого процедуры использовать?
20 окт 04, 14:46    [1048561]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 SanyL
Если это было сравнение с Oracle, то все пункты кроме 4 и7 не ясны в плане превосходства SQL над Oracle. Например, пп.1 - мало ли где легки триггеры в написании. И в чем выражать легкость и сложность?
пп 4 Превосходство Oracle. И оно важное, поскольку меньшая зависимость от платформы имеет значение. Тем более, что на серверах пока Винды еще не захватили 100 % на рынке.
пп 7. Кому как насчет удобства. Если я знаю лучше Oracle, то он мне и кажется удобнее. Наверное речь шла о том, что быстрей освоить с нуля. И то дело наживное. Кроме того, у Оракла достаточный резерв для настроек под конкретные задачи на разных этапах эксплуатации. Ведь если нельзя подкрутить а надо, то насколько это удобно?
Что касается памяти, то тоже не ясно. А где СУБД будет производить все вычисления? И как? Зависит от ИС в которой используется БД. Оракл 8 менее требователен к памяти, чем 9, но все-таки мне 9 больше нравится. А для маленьких задач у Оракла есть и редакции соответствующие. А если корапаративное решение, то там память на серваке все равно в гигабайтах меряется. Сколько нужно памяти серверному процессу для сортировки сотен мегобайт?
Не очевидно, что пречеслино все необходимые для сравнения показатели.
Например, про кластеры ничего не сказано.
Кроме того, мы заинтересованы в своих СУБД, и врядли можем достаточно объективно их сравнить. Еще нужно знать хорошо обе СУБД и иметь опыт участия во многих проектах.
20 окт 04, 17:36    [1049599]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
SanyL
Member

Откуда: Москва
Сообщений: 4540
Нет, я не пытался сравнить мс сиквел с ораклом.... и по поводу того что трудно быть адекватным (оракл 2е недели всего как интересовать меня стал) я согласен... = просто пытался сказать в защиту мс сиквела и АДО и прочей дребедени = а то в топике столько наездов на это все было...а главное что голословных наездов... и даже скажу более - я признаю оракл более мощной СУБД чем мс сиквел (это мое интуитивное и необоснованное мнение)
22 окт 04, 00:07    [1053200]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Я тоже признаю Оракл более мощной БД, чем MS SQL, но только при использовании Оракловых кластеров

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

Откуда: Обнинск
Сообщений: 4802
Я, естественно, тоже пока признаю Оракл более мощной. Но интуитивно. И признавал, когда работол (не долго с MS SQL 7). Но по слухам.
Помню, что тогда меня разочаровало то, что при написании триггеров, для того, чтобы узнать значение поля изменяемой таблицы до изменения и после во время транзакции, нужно просматривать было специальные таблицы updated и deleted. Но если в одной транзакции меняется много значений поля одной таблицы, то чтобы узнать что на что поменялось нужно как-то соединять эти специальные таблицы. В результате возникли трудности с реализацией каскадного обновления. Чтобы проверить как правильно, я предложил ERWIN сгенерить такой триггер.
Он сгенерил триггер, который работал только при изменении одной записи, а в случае обновления нескольких записей выдавал исключение. А поскольку у потомка может быть еще потомок, то в общем случае должно обновляться несколько записей.
Когда увидел, что у Оракла есть псевдоколнки, в которых есть старое и новое значение весьма обрадовался.
Впрочем, это детали конечно. Это не главное. Да и когда это было.
22 окт 04, 16:43    [1055442]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Так у кого были проблемы с тригерами? У MS SQL или Oracle? Если у MS SQL то там во-первых никогда таблицы updated не было, во-вторых ничего никуда отсоединять не надо...
22 окт 04, 17:17    [1055557]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 17   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить