Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 11 12 [13] 14 15   вперед  Ctrl
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67512
Блог
Leonid Kudryavtsev
Ситуация редкая, но пару раз мне такие запросы делать пришлось

Но делали. И это как раз одна из тех вещей, которые бы стоило улучшить вместо того, чтобы приделывать ещё один синтаксис. Это ведь не какое-то идеологическое преимущество ansi-синтаксиса, это просто "в своё время недоделали и закрыли workaround-ом, а теперь вместо того, чтобы сделать нормально, приделали ansi-синтаксис с его проблемами и недостатками".

Leonid Kudryavtsev
Но ANSI синтаксис, в любом случае, намного понятнее

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

from
  ... outer join (select * from t where a = 1) t on (t.b = 2)
where
  t.c = 3


три условия размещены в трёх местах и означают три разные по смыслу вещи. Наверное, можно сказать, что это дело привычки, во всяком случае доказать обратное будет затруднительно. Во всяком случае, если говорить о новичках и начинать с inner join, лично я не представляю, как объяснить ansi-синтаксис, чтобы он оказался удобнее и понятнее, нежели where-овский.
7 окт 14, 16:48    [16672365]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67512
Блог
Leonid Kudryavtsev
Лично мне, вообще реалиционная алгебра и "SELECT" не нравятся. Т.к. отучают думать о структуре БД

Это довольно частый случай. Выглядит он примерно так: есть некоторое решение А. Все им пользуются, понаступали на грабли, изучили недостатки. Приобретённый опыт приводит к разработке решения Б, ликвидирующего эти недостатки, все радуются. Проходит сколько-то лет, приходит новое поколение, которое в какой-то степени обстучалось о недостатки подхода Б, но при этом не имеет личного опыта работы с А - и оно, забыв, не зная либо просто недооценивая его недостатки, начинает изобретать А заново, искренне уверенное, что так лучше.

Leonid Kudryavtsev
программист и все причастные должны были неизбежно думать о структуре БД, что было и не плохо.

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

Leonid Kudryavtsev
То в большинстве случаев для ввода данных и OLTP систем, как мне кажется, "select" это просто какое-то извращение. Сейчас, половина битвы за эффективность - это борьба С оптимизатором.

Я не очень представляю себе, как превратить ввод данных и однострочные запросы в борьбу с оптимизатором.
7 окт 14, 16:57    [16672440]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
mayton
Member

Откуда: loopback
Сообщений: 53031
softwarer
три условия размещены в трёх местах и означают три разные по смыслу вещи. Наверное, можно сказать, что это дело привычки, во всяком случае доказать обратное будет затруднительно. Во всяком случае, если говорить о новичках и начинать с inner join, лично я не представляю, как объяснить ansi-синтаксис, чтобы он оказался удобнее и понятнее, нежели where-овский.

Я долго подбирал слова. Но похоже у вас получилось лучше.
7 окт 14, 17:00    [16672455]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
softwarer

from
  ... outer join (select * from t where a = 1) t on (t.b = 2)
where
  t.c = 3




вот это как раз не правильно. Если так сделать то получится тупо CROSS JOIN, вот если бы было типо on t.b = t1.a, тогда верно.
7 окт 14, 17:11    [16672523]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9900
softwarer
Это ведь не какое-то идеологическое преимущество ansi-синтаксиса...

На мой взгляд именно "идеологическое преимущество"

В Ansi синтаксисе очевиден (задан) порядок и условия соединения таблиц. В стандартном синтаксисе, эта информация изначально отсутствует. А при наличие связи outer join вида "одна таблица со многими", результат будет зависит от того, в каком порядке мы обходим таблицы.

Но тут проблема не в Oracle, а изначальная идеологическая проблема релиционно баз данных и select'а, что из where и = можно автоматом (оптимизатором) восстановить структуру (сетевую) базы данных и [b]эффективно[b] извлечь данные. Обломись. Хорошо было в теории, полно глюков на практике.

Меня, как разработчика, и оптимизатор и select бесят. Мне не нужно, что бы оптимизатор как-то "догадывался" и делал предположения о структуре базы данных. Я, как разработчик, структуру базы данных _знаю_. Я знаю, в каком порядке и как в моей структуре/модели (сетевой) расположены объекты предметной области (таблицы) и как _я_ планировал их объединять и с ними работать.

В этом плане, ANSI синтаксис как-бы шаг назад. Он совершенно точно воспроизводит логику работы команд Dbase/FoxPro set relation to. Указали РУКАМИ порядок и условия объединения таблиц, из реалиционных таблиц программист руками собрал иерархическую структуру, вернули данные. Все руками программиста )))

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

MS с оптимизатором не стала мучиться и изначально придумало синтаксис "как раньше". А потом сделало его стандартом. AFAIK
softwarer
...и я предпочитаю видеть все условия на таблицу вместе...

Я не пытаюсь видеть "условия на таблицу". Мне на таблицу пофиг. Я пытаюсь понять структуру данных. Что, где и в какой последовательности размещено в БД. Своего рода кусок ER-диаграммы.

А вот за "условиями на таблицу" когда таблиц 10-15, за "деревьями леса не видно". Особенно когда таблицы х.з. в какой последовательности перечислены во from и/или раскиданы по подзапросам. IMHO
7 окт 14, 17:15    [16672547]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
Leonid Kudryavtsev
В этом плане, ANSI синтаксис как-бы шаг назад. Он совершенно точно воспроизводит логику работы команд Dbase/FoxPro set relation to. Указали РУКАМИ порядок и условия объединения таблиц, из реалиционных таблиц программист руками собрал иерархическую структуру, вернули данные. Все руками программиста )))


Вот это бред. Порядок соединений таблиц важен только для LEFT и RIGHT JOIN. INNER JOIN можно написать любой порядок, а уж оптимизатор сам решит как выгодней соединять таблицы.
7 окт 14, 17:19    [16672571]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67512
Блог
Симонов Денис
вот это как раз не правильно.

Как бы Вам сказать.... 1, 2 и 3 - это вовсе не обязательно константы, это просто маркеры для отображения трёх по-разному работающих условий. Можно подставлять туда что угодно. А вот на тему "тогда верно"... как бы это деликатно сказать... если Вы действительно уверены, что надо только так и никак иначе, то почему такой синтаксис не запретили и всё будет нормально работать? :)
7 окт 14, 17:23    [16672598]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9900
softwarer
...Угу. И при любых изменениях требовалось править кучу мест в программе. Вот, скажем, недавно я сделал такую вещь: переименовал таблицу, создал вьюху над этой таблицей, в триггерах над вьюхой посадил отладочную печать и сделал синоним, который направлял то на вьюху (работая в отладке), то на таблицу (быстро и как прежде). И никто ничего не заметил. А в том, что описываете Вы, было бы легче повеситься :)

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

1) "однострочные запросы" давно пытаюсь не делать
2) Желание отобрать данные (для последующего ввода) и посмотреть их в виде совершенно отличном от того, как они лежать в БД - встречал. Тут конечно претензия ни к базе данных, а к "архитекторам", которые такое желание у пользователей в корне не задушили.

По результату - объединение >5 таблиц по hash-join + full table scan'ы. Вроде простейший запрос. В тесте все нормально (кто же смотрел на план), на пром данных все стоит колом, что и понятно.

На старых системах разработки, программисту и в голову бы не пришло такое создать... они бы просто не позволили... ))) он еще на этапе написания set rela to уже бы понял, что творит х#$ню.

Было решено изменением интерфейса. При этом, никаких претензий от аналитиков (пользователей?) не возникло. Юзабилити не пострадало.

AFAIK
7 окт 14, 17:32    [16672665]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9900
Симонов Денис
Вот это бред. Порядок соединений таблиц важен только для LEFT и RIGHT JOIN. INNER JOIN можно написать любой порядок, а уж оптимизатор сам решит как выгодней соединять таблицы.

Порядок соединения таблиц важен всегда.

"а уж оптимизатор сам решит" - только кто гарантирует, что он решит правильно. И откуда он знает, как их _нужно_ соединять? Обычно оптимизатор может просто "догадываться". Он это и пытается делать... например используя статистику... но не всегда получается )))
7 окт 14, 17:36    [16672685]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67512
Блог
Leonid Kudryavtsev
На мой взгляд именно "идеологическое преимущество" В Ansi синтаксисе очевиден (задан) порядок и условия соединения таблиц.

Это уже другая тема, не имеющая отношения к ORA-01417.

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

Leonid Kudryavtsev
А при наличие связи outer join вида "одна таблица со многими", результат будет зависит от того, в каком порядке мы обходим таблицы.

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

Leonid Kudryavtsev
Меня, как разработчика, и оптимизатор и select бесят. Мне не нужно, что бы оптимизатор как-то "догадывался" и делал предположения о структуре базы данных. Я, как разработчик, структуру базы данных _знаю_.

Когда разработчик отдаёт базу в продакшн, а через пару лет вдруг на неё смотрит, он бывает сильно удивлён :)

Leonid Kudryavtsev
В этом плане, ANSI синтаксис как-бы шаг назад. Указали РУКАМИ порядок и условия объединения таблиц, из реалиционных таблиц программист руками собрал иерархическую структуру, вернули данные. Все руками программиста

Скажу коротко: никто не мешает оптимизатору выполнить соединения не так, как написано в join-ах. Я даже уверен, что любой вменяемый оптимизатор не сковывает себя таким образом. То, о чём Вы говорите - чисто визуальное ощущение, с тем же успехом можно потребовать, чтобы оптимизатор выполнял where-часть строго сверху вниз и точно так же "всё руками", синтаксис тут не при чём. На практике для желающих этого Оракл предусмотрел хинт ORDERED.

Leonid Kudryavtsev
Оптимизатор видя запрос и глядя на таблицы пытается догадаться какая у них структура и как их эффективно связать.

Знаете, это немного наркоманская фраза :) Оптимизатор ни о чём не гадает, структуру таблиц и многое другое он точно знает.

Leonid Kudryavtsev
Я не пытаюсь видеть "условия на таблицу". Мне на таблицу пофиг. Я пытаюсь понять структуру данных. Что, где и в какой последовательности размещено в БД. Своего рода кусок ER-диаграммы.

Запрос - не то место, глядя на которое надо "пытаться понять структуру данных". Для этого предназначены те самые ER-диаграммы и прочая документация.

Глядя на запрос, я хочу понимать логику этого запроса, логику выборки данных. И для этого мне очень удобно сначала прочитать, что в запросе участвуют ДОМА, ДВОРЫ и ДЕРЕВЬЯ (во from), потом прочитать, какие именно дома (несколько строк вместе в where), потом - какие именно дворы итп. В ansi-синтаксисе уже первое из этого - понять, какие сущности участвуют в запросе - уже требует нетривиальных усилий либо совершенно уродского форматирования.

Leonid Kudryavtsev
А вот за "условиями на таблицу" когда таблиц 10-15, за "деревьями леса не видно".

Именно. Типичная для ansi синтаксиса ситуация, когда куча условий забивает даже просто понимание, какие сущности участвуют в запросе.
7 окт 14, 17:41    [16672720]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
mayton
Member

Откуда: loopback
Сообщений: 53031
Несколько хинтов вспомилось.

Oracle(R) Database Performance Tuning Guide
LEADING

The LEADING hint specifies the set of tables to be used as the prefix in the execution plan. This hint is more versatile than the ORDERED hint.

The LEADING hint is ignored if the tables specified cannot be joined first in the order specified because of dependencies in the join graph. If you specify two or more conflicting LEADING hints, then all of them are ignored. If the ORDERED hint is specified, it overrides all LEADING hints.

ORDERED

The ORDERED hint causes Oracle to join tables in the order in which they appear in the FROM clause.

If you omit the ORDERED hint from a SQL statement performing a join, then the optimizer chooses the order in which to join the tables. You might want to use the ORDERED hint to specify a join order if you know something about the number of rows selected from each table that the optimizer does not. Such information lets you choose an inner and outer table better than the optimizer could.
7 окт 14, 17:45    [16672751]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67512
Блог
Leonid Kudryavtsev
Ну как-то на FoxPro приложения разрабатывали и не вешались

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

Leonid Kudryavtsev
"однострочные запросы" давно пытаюсь не делать

Ну, тем не менее это естественная, правильная и даже пожалуй что основная составляющая oltp-запросов.

Leonid Kudryavtsev
Было решено изменением интерфейса. При этом, никаких претензий от аналитиков (пользователей?) не возникло. Юзабилити не пострадало.

Ну вот и давайте отметим, что синтаксис соединений тут не при чём :)
7 окт 14, 17:45    [16672752]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
mayton
Member

Откуда: loopback
Сообщений: 53031
Leonid Kudryavtsev
Симонов Денис
Вот это бред. Порядок соединений таблиц важен только для LEFT и RIGHT JOIN. INNER JOIN можно написать любой порядок, а уж оптимизатор сам решит как выгодней соединять таблицы.

Порядок соединения таблиц важен всегда.

"а уж оптимизатор сам решит" - только кто гарантирует, что он решит правильно. И откуда он знает, как их _нужно_ соединять? Обычно оптимизатор может просто "догадываться". Он это и пытается делать... например используя статистику... но не всегда получается )))

Честно говоря иногда очень хотелось иметь не столько язык запросов сколько язык
конструирования экзекюшен планов. Это не кивок в сторону Ansi а скорее размышления
на тему API и возможностей разработчика влиять на различные непредвиденные ситуации
в продуктиве а также желание поймать "стабильность".
7 окт 14, 17:48    [16672762]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
softwarer
Симонов Денис
вот это как раз не правильно.

Как бы Вам сказать.... 1, 2 и 3 - это вовсе не обязательно константы, это просто маркеры для отображения трёх по-разному работающих условий. Можно подставлять туда что угодно. А вот на тему "тогда верно"... как бы это деликатно сказать... если Вы действительно уверены, что надо только так и никак иначе, то почему такой синтаксис не запретили и всё будет нормально работать? :)


А это потому что можно написать например вот так

select *
from t1 
left join t2 on t1.a=t2.a and t2.b = 2
where t1.c = 1


и результат такого запроса будет отличаться от того если бы условие t2.b = 2 переместили в секцию where. В общем ANSI синтаксис запросов ничуть не хуже, просто его надо понимать.
7 окт 14, 17:51    [16672779]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67512
Блог
Симонов Денис
и результат такого запроса будет отличаться от того если бы условие t2.b = 2 переместили в секцию where.

Да, именно об этом я и писал в том посте, который вызвал Ваше "неправильно". Теперь Вы это повторяете. Смысл беседы?

Симонов Денис
В общем ANSI синтаксис запросов ничуть не хуже, просто его надо понимать.

Ну, лично я предпочитаю синтаксис, который можно просто "легко читать", без необходимости "специально понимать". Но основной вопрос имхо не в том, что лучше-хуже, а в том, что глупо осложнять жизнь наличием двух практически эквивалентных инструментов.
7 окт 14, 17:55    [16672801]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
softwarer,

ну для тех кто программирует исключительно на Оракл наверное так оно и есть. И если INNER JOIN во всех СУБД можно написать без JOIN, то c OUTER JOIN будет засада.
7 окт 14, 17:59    [16672821]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9900
softwarer
А теперь попробуйте взять и сделать какую-нибудь задачу на "тех" инструментах

ну я последние 15 лет большинство задач на C делаю на голом Win-API ))). Просто задачи небольшие. А нафига тащить в проект огромные "современные" библиотеки.

В тех случаях, когда для скорости использовался Borland C builder и VCL (его библиотека визуальных компонентов) - через пару лет пришлось переделывать на "тех инструментах" выкидывая VCL ))). Т.к. вызывало много проблем в эксплуатации и сопровождении (начиная от чрезмерных требований к памяти)
7 окт 14, 18:08    [16672870]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
mayton
Member

Откуда: loopback
Сообщений: 53031
Leonid Kudryavtsev
ну я последние 15 лет большинство задач на C делаю на голом Win-API ))).

Мозохист. Чтож это за задачи такие? Кейгены? Кряки?
7 окт 14, 18:21    [16672938]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
prog123
Guest
Возврат к командной строке неизбежен, но это будет уже 3D-строка:)
7 окт 14, 18:32    [16672994]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9900
Библиотеки для чего нибудь более высоко уровневого )))

например: показ изображений для FoxPro и Oracle Forms, ф-ции для Oracle Forms (например ввод-вывод, аналог TEXT_IO, с поддержкой UTF8), мультимедия и спец.эффекты для Macromedia Directora и так далее, вызов ГОСТ шифрование (Crypto Pro CSP) для Java.

Получить .DLL размером в пару мегабайт и/или в 10-20 Kb - в общем, разница есть ))) Особенно когда у клиентов (начало 200-х годов) компьютер с 32 Mb оперативной памяти, которая нужна прикладной системе на Oracle Forms, а половина памяти "отъедается" VCL который пришел вместе с _единственным_ вызовом одной ф-ции на C++ Builder'е, которая требуется для загрузки приложения.... можно конечно и так жить ))), но с учетом тиражируемости системы, все библиотеки были переписаны на MS VC и весь "современный хлам" просто выкинут ))).

Ну или создавать ActiveX контрол, когда просто "поле для ввода" занимает 5-10 Mb - это IMHO перебор )))
7 окт 14, 18:41    [16673027]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
prog123
Guest
Leonid Kudryavtsev
Библиотеки для чего нибудь более высоко уровневого )))

например: показ изображений для FoxPro и Oracle Forms, ф-ции для Oracle Forms (например ввод-вывод, аналог TEXT_IO, с поддержкой UTF8), мультимедия и спец.эффекты для Macromedia Directora и так далее, вызов ГОСТ шифрование (Crypto Pro CSP) для Java.

Получить .DLL размером в пару мегабайт и/или в 10-20 Kb - в общем, разница есть ))) Особенно когда у клиентов (начало 200-х годов) компьютер с 32 Mb оперативной памяти, которая нужна прикладной системе на Oracle Forms, а половина памяти "отъедается" VCL который пришел вместе с _единственным_ вызовом одной ф-ции на C++ Builder'е, которая требуется для загрузки приложения.... можно конечно и так жить ))), но с учетом тиражируемости системы, все библиотеки были переписаны на MS VC и весь "современный хлам" просто выкинут ))).

Ну или создавать ActiveX контрол, когда просто "поле для ввода" занимает 5-10 Mb - это IMHO перебор )))


У меня высоконфункцилнальные программы на Delphi 7 (а не одна какая то форма:)) занимают 1.5 - 2 Мб.
7 окт 14, 18:56    [16673093]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
mayton
Member

Откуда: loopback
Сообщений: 53031
Это тот самый Forms? Двузвенка?
7 окт 14, 18:56    [16673094]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 9900
P.S.
+

Как пример:

Из-за различных версий OCI библиотек был такой замечательный эффект, что основное приложение лезло в один Oracle home (Developer'а), а подгружаемые компоненты и библиотеки в другой Oracle client или Oracle Server 8.1.5. В целом, достаточно весело, когда посреди работы приложения получаешь TNS ошибку name not found )))

Разумеется, какие версии OCI "правильные" то известно только разработчикам Oracle Forms ))), не говоря уже о том, что похоже они не стандартный PRO*C, OCI пользуются, а какой-то спец. сборкой. Т.к. кроме чисто клиентского PROC*C библиотек, у них еще и какие-то куски от сервера вырезаны (интерпретатор PL/SQL). Понятно, что достать "правильную" версию и слинковать с ней не возможно. Это нужен доступ к исходному коду Forms'ов.

Т.ч., де факто, в одном приложении две версии OCI, которые могут схватить разные хоумы )))

Аналогично MFC. Уже не помню, но долго мучался, пока правильные параметры линковки поставил. У MS специальная дока есть, использование MFC в библиотеках, которые вызываются из приложения слинкованного с другой версией рантайма и MFC )))

В общем, чем меньше современного хлама добавляешь в проект - тем спокойнее и меньше вероятность, что все упадет. Особенно печалит, когда все написано и вроде все работает (в продакшене уже пару лет), а тут неожиданно выясняется, что в редких случаях получаешь ошибку выделения памяти и GPF, т.к. разные менеджеры памяти от разных run time. Просто раньше на эту ошибку не нарывались. И, что называется, "приплыли". Код написан, работает в продакшене, а переделать "правильно" никак (см. выше, х.з. как слинковаться с правильным run time) )))

Аналог, Java и ADF библиотеки. Х.з. как на одном Weblogic домене задеплоить два приложения с разными версиями ADF ))) А уж в продакшен к заказчику я бы такое тем более ставить не стал )))
7 окт 14, 19:20    [16673181]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67512
Блог
Leonid Kudryavtsev
Получить .DLL размером в пару мегабайт и/или в 10-20 Kb - в общем, разница есть

Не особо. Если, конечно, вопрос не в том, что делаешь двадцать dll размером в пару мегабайт каждая.

Leonid Kudryavtsev
а половина памяти "отъедается" VCL который пришел вместе с _единственным_ вызовом одной ф-ции на C++ Builder'е, которая требуется для загрузки приложения.... можно конечно и так жить ))),

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

Отдельный интерес - как собрать эту DLL так, чтобы она "занимала половину памяти" хотя бы в виде файла на диске.... я уж не говорю про то, сколько она будет на самом деле занимать в памяти. Я вот пожалуй не возьмусь представить, что надо запихать, чтобы "ради одной функции" собралось 16 метров. У меня полнофункциональные приложения гораздо меньше :)
7 окт 14, 19:28    [16673206]     Ответить | Цитировать Сообщить модератору
 Re: Firebird vs Oracle для БД до 200 Gb и 50 пользователей при нагрузке OLTP  [new]
Dimitry Sibiryakov
Member

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

Leonid Kudryavtsev
Т.ч., де факто, в одном приложении две версии OCI, которые могут
схватить разные хоумы )))

И вот тут возникает резонный вопрос: в чём смысл иметь на машине несколько клиентов
Оракула да ещё и с разными хомами? Неужели один, самый свежий, клиент неспособен работать
с несвежими серверами?..

Posted via ActualForum NNTP Server 1.5

7 окт 14, 19:34    [16673230]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 11 12 [13] 14 15   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить