Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 11 12 13 14 15 [16] 17 18 19 20 .. 23   вперед  Ctrl
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
andy st
а какие они, более прямые пути ???

Поставить hsodbc/hsolexxx на виндовую машинку, скорее всего на ту, на которой крутится целевой mssql, и работать через него. Мне это представляется более надежным, чем использовать хакерские вещи типа FreeTDS.
30 янв 07, 12:58    [3712528]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
kennethr
Gluk (Kazan)
Банальными view.

Так и подумал, что меня в view ткнут. :-) Преимуществ по идее никаких. Хотя в процедуру можно "запихнуть" не только запрос. Меня просто удивило отрицание такой возможности. И потом, вы не ответили на вопрос об Enterprise версиях.
Еще, не забыли про тот баг с редактированием view?


Вы забыли упомянуть о преимуществах ВАШЕГО подхода
30 янв 07, 13:00    [3712545]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
locky
Member

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

andy st wrote:
> Автор: andy st <https://www.sql.ru/forum/memberinfo.aspx?mid=26233>
> Gluk (Kazan)
>
> Мы работаем с Oracle и MS SQL. Когда пришлось выбирать между OLE DB и
> ODBC, выбрали последний. В силу жизненной задачки, описанной чуть выше.
>
>
> разговор был про linux
> насколько я в курсе оттуда в mssql можно попасть только FreeTDS (других
> путей я не знаю, просвятите плз, если есть).
> ODBC идет через тот же FreeTDS, объявленный Softwarer-ом извратом.
> так какие же есть ДРУГИЕ пути доступа из под oracle на unix-подобных
> системах к не-oracle ?
Из под линуха к MS SQL Server можно ходить:
1. FreeTDS - поделка на коленке, но для некритичных приложений - сойдет,
хотя нет кое-каких фич "нормальной" db-library. MS её не поддерживает.
2. DataDirect ODBC Driver. Технологический партнер MS. Кроме SQL Server
предоставляет также дрова еще для нескольких СУБД.
3. Easysoft ODBC Driver/bridge. Собственно прямой ODBC драйвер находится
в состоянии бэта-версии. bridge требует установки серверной части
"моста" на win-машину.

Posted via ActualForum NNTP Server 1.3

30 янв 07, 13:01    [3712551]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
andy st
Gluk (Kazan)

Мы работаем с Oracle и MS SQL. Когда пришлось выбирать между OLE DB и ODBC, выбрали последний. В силу жизненной задачки, описанной чуть выше.

разговор был про linux
насколько я в курсе оттуда в mssql можно попасть только FreeTDS (других путей я не знаю, просвятите плз, если есть).
ODBC идет через тот же FreeTDS, объявленный Softwarer-ом извратом.
так какие же есть ДРУГИЕ пути доступа из под oracle на unix-подобных системах к не-oracle ?


А что с OLE DB ситуация на Linux-е значительно лучше ???
JDBC, в том числе тонкий клиент
30 янв 07, 13:01    [3712556]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
kennethr
Еще, не забыли про тот баг с редактированием view?


Только не надо утверждать, что Вы давно о нем знали
30 янв 07, 13:08    [3712613]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
andy st
Member

Откуда:
Сообщений: 906
softwarer
andy st
Странные выводы делает человек о вкусе ананасов, даже не попробовав их... :)

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

да и мне малость приходится... зоопарк однако на предприятии, mssql 7,2000 ораклы от 7 до 10... и еще куча всего.... вот и изголяемся....

softwarer

andy st
Без этого получается, что все современные технологии программирования - сплошные побочные эффекты. И вооще mssql и пр. не-oracle - побочные эфекты программирования. :)

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

а разве я не написал прямым текстом то, что Вы ваулируете на протяжении последних нескольких страниц?

softwarer

andy st
Честно. Складывается такое ощущение, что Вы в принципе не признаете возможность сущществования чего-то более совершенного,



Нашли тоже более совершенное. Судя по всему, переменная @@ERROR для Вас более совершенна, чем механизм исключений, ну и так далее.

он УЖЕ есть в mssql ... расслабьтесь....
а вот DDL в транзакциях и вменяемого аналога openrowset в Oracle так и не нашли.

softwarer

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

а Вы доказательства разве приводите?
Только утверждения, изредка ничем необоснованные... или основанные на своем опыте, которым в отношеннии mssql (исходя из частых упоминаний древних версий сего продукта) можно пренебречь.
и исходя из того, что Вы что-то тут пишете - времени у Вас немеряно. :)

softwarer

andy st
А в C/C++ есть фичи, которые даже стандартом не описаны (типа i++=++i;) - вообще можно выпить йаду?

Если Вы не знаете стандарта - это не повод говорить, что такие фичи там не описаны. Мало того, в соответствии со стандартом написанное Вами даже должно иметь четко определенный результат (в отличие от i++=i++ - вот тут в соответствии со стандартом результат будет неопределенным).

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

softwarer

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

а по поводу отношения к функции printf и подобным в Вы определились?

softwarer

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

Я не готов рассуждать о Вашем практическом опыте и даже не собираюсь спорить с ним. Не наблюдали - и хорошо. Значит, в MSSQL есть дыра, которую в знакомых Вам системах успешно обходят, в Oracle такой дыры нет и беспокоиться об ее обходе не нужно. При этом до сих пор никто не назвал хотя бы одной реальной пользы, приносимой этой дырой именно в таком виде, все сводится к "привычнее" и "жаль, что Oracle не дыряв так, как MSSQL, поставим ему за это минус".

вот только разработчики mssql то и не в курсе, что это дыра.
сообщили бы Вы им...
30 янв 07, 14:01    [3713192]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
andy st
а вот DDL в транзакциях и вменяемого аналога openrowset в Oracle так и не нашли.


О дааа это убойные фичи.
Аналог FGAC в MS SQL назвать не затруднит ?
30 янв 07, 14:14    [3713320]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
andy st
Member

Откуда:
Сообщений: 906
softwarer
andy st
а какие они, более прямые пути ???

Поставить hsodbc/hsolexxx на виндовую машинку, скорее всего на ту, на которой крутится целевой mssql, и работать через него. Мне это представляется более надежным, чем использовать хакерские вещи типа FreeTDS.

если админы win-сервера дадут что-то поставить. зоны ответственности сливаются.
а целевая машина не windows и субд не mssql.
реальная цель - промышленная система на qnx 4.25 с СУБД Sybase SQL Anywhere 5.0
драйверы есть только под qnx и под windows
предложенные locky варианты тоже не прокатывают (хотя DataDirect ODBC Driver походу, интересная штука, спасибо)
30 янв 07, 14:17    [3713355]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
kennethr
Member

Откуда:
Сообщений: 175
andy st
а вот DDL в транзакциях и вменяемого аналога openrowset в Oracle так и не нашли.

Вроде бы уже договорились, что эти фичи в Oracle не нужны и даже вредны. Про DDL вообще речи не идет, а применение аналогов openrowset вполне логично под контролем DBA.
30 янв 07, 14:19    [3713381]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
против мнения я не возражаю. Я возражаю против выдвижения его в абсолютные истины без эксперимента.


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

softwarer
Хм. Спросите еще "почему в зависимости от уровня изоляции запрос должен возвращать разные выборки".....


Вы хотите задать этот вопрос человеку, "не знающему SQL"?! М.б. и здесь у нас точки зрения на уровень программистов, "не знающих SQL" отличаются?! Как то опять Вы уровень знаний "не знающего" подтягиваете под свои нужды.

softwarer
Это разные объекты (даже незнающий программист "из общих соображений" вполне поймет, что VIEW и PROCEDURE - вовсе не обязательно одно и то же). Нет ничего удивительного, что у них разные требования. Впрочем, абсурдность этого Вашего аргумента особенно ярко видна в табличном виде:
...
Итого, если Вы полагаете страшной разницу между результатами команд в первой строке, вопрос: полагаете ли Вы столь же страшной разницу между результатами команд во второй строке? Почему?


М.б. Вы вместо строк имели ввиду столбцы? Ибо я как раз полагал о том, что для "не знающего SQL" поведение SELECT во вью и в хп не должно различаться:

pkarklin
С чего бы это "не знающему SQL программисту" надо различать:
CREAT VIEW ... AS SELECT... и CREATE PROC ... AS SELECT...? Почему в одном случаи SELECT что-то возвращает, а во втором он недолжен ничего возвращать.


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

softwarer
Мы говорим о прозрачности. Прозрачность - это когда Вы (знающий MSSQL), я (знающий SQL, но не MSSQL) и программист, не знающий SQL, имеем хорошие шансы понять что-то одинаково. Если же из нас троих "надежно понятно" только Вам - это обозначается каким угодно словом, но только не "прозрачно".


Интересный подход. Пока в этом обсуждении всем, кто знает MS SQL такой подход кажеться прозрачным, и, всем, кто знает Oracle с точностью до наоборот. Исходя из каких предпосылок Вы сделали вывод, что прозрачность на самом деле кажусяяся и причем только мне. Только из-за того, что Вам она кажеться не прозрачной? В данном случае Ваше мнение выступает мерилом абсолютной истины? Двойные стандарты, уважаемый Александр?!

softwarer
Ага, знакомая песня. Итого, одни будут учить SQL, потом PL/SQL. А другие - не будут ничего учить, зато будут создавать программы, от которых уши дыбом встают.


Не надо передергивать!!! Программы, от которых "уши дыбом встают" (кстати, почему уши, у меня обычно волосы) могут создаваться (и самое главное создаются) и на PL\SQL. Это ни есть характеристика инструмента! Это есть характеристика использующего этот инструмент!

softwarer
Плюньте в лицо тому, кто сказал Вам такую глупость. Бред какой-то, такое впечатление, что Вы придумываете на ходу.


Нет я не придумываю. Плюнуть в лицо не получиться, ибо примеры такой реализации я нашел в интернете.

softwarer
Для незнающего оба варианта будут по большому счету непрозрачны. Что и требовалось доказать.


Интересно, что и кому Вы доказали?! Вы сами себе доказываете, что Вы правы. Ради бога. Для меня Вы пока ничего не доказали. Да и как можно что-то доказать, если нет у собеседников абсолютно разные взгляды на доказуемую область, а именно ее "прозрачность".

softwarer
В случае ораклового варианта незнающий, ориентируясь на
...

В случае MSSQL-ного
...


Увы и ах. Видимо у нас, опять же, на "незнающего программиста" разные взгляды. У Вас как не посмотришь, так он уже родился с мыслью о том, что из процедуры можно что-то вернуть только через параметр. Но это не так. И это реальная действительность (не только в MS SQL и не только c SELECT). Так что можно дальше продолжать доказывать, что реальная действительность далека от "прозрачности". Хотя, нет, не надо, я и так знаю Ваш ответ!

softwarer
Я тогда как раз проверял утверждение одного из Ваших коллег по поводу интуитивно понятного синтаксиса T-SQL. Проверил вполне успешно, о результате можете судить. После чего заглянул в хелп, но сохранил радость по поводу возможности легко написать вполне понятный и правильный на вид, компилирующийся, но ни хрена не работающий код.


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

softwarer
Итого, надеюсь, мысль о том, что надо читать доки, считаем доказанной?


Я где-то говорил обратное?! Вы опять поворачивает мои мысли в нужную для Вас сторону для доказательств не понятно чего. Речь шла о прозрачности для "не знающего SQL", но не для обременного некими догмами человека.

softwarer
То есть как только запрос во вью, хп или функции, он "стандартный". Как только тот же самый запрос в курсоре, он "нестандартный".


Я этого не говорил. Обратите внимание, что для меня возвращение результата запроса из хп в виде курсора оказалось не прозрачным, что собственно Вас и заставило вступить в дебаты.

softwarer
Кстати, раз уж пошла такая пьянка, сколь мне помнится, входящий в стандарт оператор INSERT в MSSQL можно делать в процедурах, но нельзя делать в функциях. Правильно ли я помню? Не смущает ли Вас этот диссонанс? Мне так кажется, между функцией и процедурой разница меньше, чем между процедурой и преставлением. Да, вот еще что. Почему это скалярную функцию в MSSQL требуется брать в begin-end скобки, а процедура запросто может обходиться без них? Неужели незнающему это будет прозрачно?


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

softwarer
Ох, любите Вы передергивать. Сначала Вы сделали некорректный переход и сказали, что я приписал Вам сделанный вывод, теперь оказывается, что это я воспользовался неоднозначностью языка и я же сделал вывод.


У меня есть у кого учиться.

softwarer
В первую очередь Вы как профессионал должны знать, что толковый ответ можно дать только на толковый вопрос.


Согласен, что на глупые вопросы тяжелее всего отвечать. Но отвечать на них анекдотами...

softwarer
И наконец, Павел, позвольте дать Вам совет. Если Вы будете каждый случай своей неправоты воспринимать как следствие некорректных приемов оппонентов (как сейчас Вы назвали процитированное "непрямым ответом" и "очередной эквилибристикой"), это не пойдет на пользу качеству Вашей работы. Я встречал - и наверняка, Вы встречали - таких людей, у которых каждый проект начинался с благими намерениями, а потом внезапно заказчик подставлял, программисты тупили, начальство сдавало и так далее, полная катастрофа и очередной проект с благими намерениями. Я искренне желаю Вам успехов, и потому советую выбрать какой-нибудь другой путь.


Спасибо. К советам я всегда прислушиваюсь. Но и мне, позвольте, посоветовать Вам не рассматривать свою точку зрения единственным "мерилом" чей то правоты, не взирая на возможность существования других точек зрения.

softwarer
Павел, Вы опытный программист, поэтому я в некотором замешательстве, не могу решить, то ли Вы не поняли сказанного мной, то ли делаете вид, что не поняли. Итак, давайте смотреть ситуации:

В результате изменения тела объекта P1 изменилось поведение объекта P1
В результате изменения тела объекта P1 изменилось поведение объекта P2, прямо использующего P1
В результате изменения тела объекта P1 изменилось поведение объекта P2, косвенно использующего P1

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


Александр, я думаю, Вы прекрасно понимаете, что я хотел сказать. Что сложность сопровождения определяется в первую очередь не "качеством" используемого инструмента, а тем, кто и, самое главное, как его использует. Я думаю, что и хп в Oracle, можно с имитировать описаные Вами ситуации.

softwarer
Вы безусловно вправе считать эту фичу особо прозрачной. До тех пор, пока явное большинство не согласится с Вами, это Ваша личная точка зрения, не являющаяся объективным различием.


Хм... Именно. Это моя точка зрения. Именно со своей точки зрения я поставли Oracle "-".


softwarer
Давайте так: спросите у авторов MSSQL, зачем они дали возможность возвращать из ХП несколько резалтсетов. А я воспользуюсь тем приемом, который Вы использовали чуть раньше, и спрошу у Вас: почему на том же форуме дельфы не раз и не два говорилось "вот MSSQL может вернуть сразу много резалтсетов как результат ХП, а XXXX - нет"? Почему это преимущество, ответьте как профессионал?


Вы знаете, я не могу аргументировать необходимость наличия возможности возвращения из хп нескольких резалтсетов. За все свое время я ни разу не написал такой хп. Едиственное, что я делал, это использовал системные хп, и то в QA. Поэтому "приемуществом" я это назвать не могу.

softwarer
Что же до моего профессионального ответа на вопрос - я совершенно не вижу, что плохого в том, если допустим ХП "обороты по складу" возвращает выборку приходов за период и другую выборку расходов за период.


Мы можем и это обсудить. Особенно в плане практического использования этой возможности. Особенно как потом использовать эти выборки.
30 янв 07, 14:23    [3713418]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
andy st
Member

Откуда:
Сообщений: 906
Gluk (Kazan)
andy st
а вот DDL в транзакциях и вменяемого аналога openrowset в Oracle так и не нашли.

О дааа это убойные фичи.

а типа нет?
Gluk (Kazan)

Аналог FGAC в MS SQL назвать не затруднит ?

всё те же хранимые процедуры на select с нужными обсчетами и фильтрами.
вьюшки с where dbo.check_persission(x,x,x,x)=1
или я не правильно понимаю предназначение FGAC???
поправьте, плз, если что не так
30 янв 07, 14:41    [3713604]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
andy st
Gluk (Kazan)
andy st
а вот DDL в транзакциях и вменяемого аналога openrowset в Oracle так и не нашли.

О дааа это убойные фичи.

а типа нет?


Одна не нужна у другой есть аналог

andy st

Gluk (Kazan)

Аналог FGAC в MS SQL назвать не затруднит ?

всё те же хранимые процедуры на select с нужными обсчетами и фильтрами.
вьюшки с where dbo.check_persission(x,x,x,x)=1
или я не правильно понимаю предназначение FGAC???
поправьте, плз, если что не так


Неправильно. FGAC переписывает ЛЮБОЙ запрос дошедший до сервера любым путем, довольно гибко. Обойти невозможно. А раздачу прав по хранимкам и в Oracle никто не отменял.
30 янв 07, 14:47    [3713655]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
У FGAC я вижу следующее приемущество. Если запросы идут непосредственно с клиента (т.е. зашиты явно в клиентское приложение), то реализация row level security не потребует внесения изменений в клиента. Т.е. в существующее приложение легко интегрируется RLS.

Но, разграничение на уровне строк - это частный случай построения ACL. Совсем не обязательно контроллировать на уровне строк. ACL м.б. построен на более высоком уровне абстракции. И не факт, что функционала FGAC будет для этого достаточно.
30 янв 07, 15:05    [3713807]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Yo.!
Guest
pkarklin

Но, разграничение на уровне строк - это частный случай построения ACL. Совсем не обязательно контроллировать на уровне строк. ACL м.б. построен на более высоком уровне абстракции.

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

ЗЫ. еще у оракла есть oracle label security
30 янв 07, 15:11    [3713873]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
И не факт, что функционала FGAC будет для этого достаточно.


Не факт конечно, но он достаточно гибок.
Правда его отладка ...
30 янв 07, 15:11    [3713874]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Yo.!
ЗЫ. еще у оракла есть oracle label security


Насколько я помню, это надстройка над FGAC
30 янв 07, 15:14    [3713898]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Yo.!
Guest
Gluk (Kazan)
Yo.!
ЗЫ. еще у оракла есть oracle label security


Насколько я помню, это надстройка над FGAC


угу, надстройка, как я пониамю это и есть реализация ACL.
30 янв 07, 15:18    [3713930]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
неможет, злоумышленик положит блот на ваши астракции и получит доступ куда ему вздумается.


Можете привести пример. Как он может положить болт на систему разграничения доступа к процедурам, представлениям, функциям, при этом не имя никаких прав на таблицы?!
30 янв 07, 15:18    [3713931]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Yo.!
Guest
pkarklin

Как он может положить болт на систему разграничения доступа к процедурам, представлениям, функциям, при этом не имя никаких прав на таблицы?!

как обычно - через дыру в самопальной системе разграниченя ...
30 янв 07, 15:42    [3714169]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!
как обычно - через дыру в самопальной системе разграниченя ...


Ну, понятно...
30 янв 07, 15:48    [3714223]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
Strelets12
Guest
А так все красиво начиналось :(
А потом 10 страниц о какой-то "прозрачности".
Есть же, наверное, более явные преимущества?
Как, например, в MS SQL реализована работа с регулярными выражениями?
30 янв 07, 17:52    [3715369]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Strelets12
Как, например, в MS SQL реализована работа с регулярными выражениями?
не реализована (или это подкол?)
30 янв 07, 19:43    [3715866]     Ответить | Цитировать Сообщить модератору
 Re: MSSQL или Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
pkarklin
У FGAC я вижу следующее приемущество. Если запросы идут непосредственно с клиента (т.е. зашиты явно в клиентское приложение), то реализация row level security не потребует внесения изменений в клиента. Т.е. в существующее приложение легко интегрируется RLS.

Это не единственное и даже не основное преимущество, хотя само по себе важно. Вопрос здесь не только в "запросах с клиента", сколько в интеграции, например доступе к БД со стороны Oracle Discoverer или других стандартных инструментов.

Основные же преимущества с моей точки зрения:

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

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

  • Разные задачи (ограничение прав конкретного пользователя и некоторая бизнес-функция) решаются разными программными модулями, в одной процедуре не смешиваются разные задачи. В частности, логику раздачи прав можно как угодно корректировать, отключить, либо наоборот, подключить позднее и отдельным этапом, все - не затрагивая кода бизнес-функций.
  • 30 янв 07, 20:04    [3715925]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67534
    Блог
    andy st
    softwarer
    andy st
    а какие они, более прямые пути ???

    Поставить hsodbc/hsolexxx на виндовую машинку, скорее всего на ту, на которой крутится целевой mssql, и работать через него. Мне это представляется более надежным, чем использовать хакерские вещи типа FreeTDS.

    если админы win-сервера дадут что-то поставить.

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

    Собственно, вот только сегодня я в очередной раз услышал вопрос "вот вы предлагаете Oracle XE, а у нас Oracle уже стоит, можно ли инсталлировать туда". И мне совершенно не требовалось задавать вопрос, какая у них серверная платформа. Это приятно.

    andy st
    а целевая машина не windows и субд не mssql.

    Это та, к которой писали OLE DB провайдера? Любопытная комбинация :)
    30 янв 07, 20:13    [3715947]     Ответить | Цитировать Сообщить модератору
     Re: MSSQL или Oracle  [new]
    Strelets12
    Guest
    SergSuper
    не реализована (или это подкол?)

    Нет, не подкол, я не знал, что нет. Действительно было интересно. Действительно приятная фича.
    30 янв 07, 20:18    [3715962]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 .. 11 12 13 14 15 [16] 17 18 19 20 .. 23   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить