Interbase

Примеры писать тяжело, простых не привести, на простых как раз оптимизатор и не нужен, всё дело в усложнёных примерах: несколько таблиц, несколько взаимосвязей, где объект и размазан по нескольким таблицам и несколько типов объектов собраны в одну ... , а затем на это всё наложить несколько вьюшек (простых и параметризированных) (я думаю мало кто пишет проги без вызова функций и разделения по классам), что очень важно (если ли ты не любишь вьюхи - возвращайся в "религиозные войны"), иерархичные ... и вот тут начинаются грабли ...
Говорить конкретные примеры на которые я нарывался и нарываюсь - немогу (комерческая тайна). У нас (банк) проекты размазаны в основном на 2ве СУБД (MSSQL и Oracle), большая часть (по функционалу) на MS, Оракловская в основном купленная у одной, довольно крупной разработческой фирмы. Соглашусь, что мне ненравится их подход, но ... как раз здесь можно посмотреть все особенности оптимизитора.
В MS код почти не меняется в зависимоти от нагрузки или расширения - индексы, партиции, т.е. чисто админишь ..., а Oracle - сидишь и думаешь как вывернуть запрос, чтоб он работал, индексы настроены оптимально, вьюхи тоже, а запрос не идёт. Вот и выворачиваешь в подзапросы увеличивая код ...
И сам поставщик говорит, не любим мы вьюхи - гимора много. А каков размер исходников  - пи...ц ... жалко мне нас стало. Короче - взяли планку количеством. (вот вам кандидатура на критерий)


1. Вот ты говоришь у тебя противоположный опыт, ну расскажи, где(как) это ты нарвался на грабли оптимизатора MSSQL в отличии от Oracle?
2. Если говорить только голые, так сказать "подтверждённые" факты, зайди на соответствующие страницы производителей и сравни характеристи (платформы, парадигмы ...). И нафиг эта тема не нужна.
3. И не надо беситься, если у одной платформы есть что-то лучше чем у другой. Всё равно найдётся вещь, в которой она хуже, даже намного хуже.

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

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

Ну вот и начинается  Кто знает почему у вас там оптимизатор не сработал или сработал неправильно, то ли у вас статистика не собрана, то ли запросы так написаны (коряво написанным запросом можно сбить с толку кого угодно), или эта ситуация вообще не воспроизводима - это ваша локальная аномалия.
1) нет конкретики
2) базы как ты сказал у вас разные, и значит оптимизаторы работают с разными запросами, так что не понятно что тут сравнивать
(а уж как могут писать программисты крупной разработческой фирмы, это отдельная песня)



Ну прям идиллия 
Может проще вам нанять отдельного Oracle DBA, чтобы не мучить SQL Server DBA?  



Я не говорил про оптимизатор, я говорил про общую производительность. Мы гоняли нашу базу с тестовыми данными на SQL Server и Oracle, на Oracle она работала быстрей.



Ты не понял, эта тема не про характеристики баз данных. А про то, какую СУБД выбрать новичку.



С того что эта тема для начинающих. Почему бы тут не рассмотреть партишенинг? Или кластеризацию?

Можешь чётко и внятно написать про оптимизатор для всех СУБД - напиши, я добавлю.

какие знания и навыки были у тех кто создавал эти БД? И как сильно они отличались?

Мои знания и навыки 

Еще раз: я не собираюсь доказывать что Oracle быстрее MS SQL Server-а. Я говорю про то, что для таких утверждений надо нечто большее, чем неудачный опыт эксплуатации какой-то конкретной СУБД. Сходи на tpc.org и посмотри правила проведения теста, насколько подробно они расписаны.

Давайте не будем тут народ загружать холиварами... И MS SQL Server и Oracle показывают сопоставимую производительность, т.е. производительность одного порядка и вообще занимают практически одну и ту же нишу, а именно - это базы данных enterprise уровня. Конкретные тесты могут показывать и одно и другое. 

Просто так создать базу данных и протестировать на нескольких серверах не получится. Объясню почему. У меня довольно большой опыт работы с базами данных, в частности с MS SQL Server, и когда я проектирую архитектуру базы данных, я учитываю конкретные особенности данного сервера. Зная узкие места, зная что именно работает быстро, а что не очень я подгоняю структуру базы под конкретный сервер. Стоит переставить эту базу данных на другой сервер, даже на такой близкий как например с MS SQL Server 7.0 На MS SQL Server 2000 и эта же самая база данных будет показывать на порядок (!) меньшую производительность, ибо узкие места другие (!). Я никогда не буду делать архитектуру одинаковой для MS SQL Server 7 и MS SQL Server 2000! Что уж говорить о тупом переводе базы данных на другую платформу! Там будет тормозить всё! 

Сама идея переносимости баз данных, как и универсальность SQL - есть вещь до крайности эфемерная, годящаяся только для того чтобы показать презентацию в Power-Point для улучшения продаж. На деле, чтобы сколь-нибудь сложная система (а рассматриваемые сервера предполагают вовсе не десяток таблиц с сотней записей) давала хорошую производительность приходится тратить огромное время на подгонку архитектуры и кода именно под данную платформу, а вовсе не под абстрактный сервер.

LSD, либо ты не понял, либо невнимательно читаешь.
Выложить не могу юридически. А потратить N дней на пример с нуля - нет на это времени.
Ага и Oracle это не СУБД. И нефиг сравнивать пролог с асемблером.
Работаю не в компании по сравнению СУБД и которые тестят одно и тоже на всём нипопадя, я просто имею вазможность разрабатывать/прогать в нескольких СУБД несколько разных проектов. И не 1, и не 10 запросов и архитектур проектирования.
В том что делаю я, они не причём.
У них подход разный из-за разной специфики - они-то пишут не для одного и не 10-х заказчиков. Браузер Opera написан на библиотеке Qt и плевали они на особенности виндов, линухов и тем более маков. Поэтому они обходят все косяки за километр проторенной дорожкой.
А мене приходится испытыватьь на прочность все аккуратно расставленные грабли используемых систем.

На счёт примера: я вот всё надумываю привести простой пример косяка SubString в MSSQL2005 и сложно сходу. А ты с отимизаторами лезешь ...

А зачем нам SQL Server DBA?
Админ админом (хотя слюни от MSSQL у него текут, а от Oracle стали слёзы), а проектироващик иногда о пролитой крови должен думать ...

Согласен, либо статистика, либо корявость, либо аномалия ... ;)
Кстати про тесты, на тестовые машины нам поджимают, и бывало, что на тесте грабли, на основном идеально. Ну наоборот это конечно. Да статистика и пропорции влияют. Про Oracle ваще молчу - море нюансов.
Кстати, ты говоришь на обоих одно и тоже ... не все подходы на одной системе реализуются на другой. А некоторые вещи принципиальны. Ну таже проблема с глубиной графа вьюшек (извини не ношу с собой блокнота - перечень различий в подходе и реализации). Когда всё процедурами, да по строчке, да логически простые запросы, да на простом проекте - удержимо. А когда всё сложней и сложней - нет здесь маштабируемости. Можно и значения независящии от цикла пихать в него при малых итерациях. И иногда приходят времена, кодась и последний наварочанный макдональд-дуглас не помогает, для преодаления звукового барьера. Так что сказать, что ассемблеровские вставки в прологе работает хуже, чем на самом асемблере... И что, и что что хуже (удивился, если наоборот). Нет плоский подход в сравнении не пойдёт. Oracle быстрее, да пусть хоть новый MSSQL 2008 обгонит, пофигу, но если скажут, что вот в 13 версии Oracle поработали над оптимизатором (возможностям сложных запросов и их проектированию), вот тогда я порадуюсь ...
Но у них другой подход ...
Ладно повторяюсь, тут народ получше всё разжёвывает...

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

Светлые и большие у тебя мысли, и малые у меня зн... э... возможности.

То что сделал Vit - за это огромное спасибо. В принципе, в принципе, нюанс, что сложное (логически) на MSSQL (имхо) легче даётся чем на Oracle не так особо важен для 6 пункта темы, в купе с другими.

Вот мне интересно, вот бесплатные или дешёвые СУБД, как они там развиваются, может статься в недалёком будущем, что мне легче закачать бесплатную, реактивную и очень удобную Оперу э.. что-то там, чем юзать тупой, глючный, тормознутый IE MSSQL и тем более Netscape Oracle? Или никакой радужной перспективы, так как специфика задач и направлений определяет здесь всё. Как говорится не по зубам, а и не нужно.

5 копеек: Кстати, XML на MSSQL мощен, но XSLTрансформацию SQL не обойдёт, да и не сравнивается, хотя одно другому не мешает. Да что такое XML ваще ...

Это сообщение отредактировал(а) Mnior - 12.1.2008, 12:09

Да я вообщем-то и не настаивал, я просто говорил что твои утверждения голословны 



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



И что стого? Я вижу, что SQL Server ты лучше знаешь, его идеология тебе больше нравится, вполне естественно, что приложения написанные под него лучше работают, т.к. лучше соответсвуют архитектуре сервера.

Oracle не плохой у него другое направление. (блин, пишу это в третий раз)

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

крайне некомпетентный и вредный совет.(к афтору темы...)

Это сообщение отредактировал(а) MrCherry - 19.4.2008, 10:22

Аргументируй.

ниправда

MySQL жёстко унижен.
Как гугл и яху на нём своио громенные данные хранит, если мускул такой плохой, как в этой теме.
5.1 выйдет - будет вообще шикарно.. 

Это сообщение отредактировал(а) LSD - 22.4.2008, 11:37

1. Выбирай выражения!
2. Насчет PostgreSQL это на значит, что он не работает на других платформах. Это просто значит что для него родной платформой является Linux, в том же Windows он работает через Cygwin.
3. Насчет Google и Yahoo: ни одна СУБД не справится с теми нагрузками которые создает поисковик, ни Oracle, ни DB2, ни SQL Server. Основная заслуга лежит на программистах Google и Yahoo которые создали такую систему распределения нагрузки которая практически не зависит от производительности СУБД. Ну заменим одну СУБД на более производительную, сможем сократить количество машин в кластере на 5-10% процентов, что вообщем погоды не делает. Тем более что вроде Google использует MySQL исключительно как front end, а storage engine у них свой.

Есть древний мускул 4.0.17. Надо обновляться. Мускул 5.1 или мсскл 2008?
Различия в лицензии можно не учитывать (мсскл достался бесплатно по партнерской программе), интересует только техническая сторона.

Нагрузка на СУБД не особо большая: 15-20 постоянно соединенных (из интранета) с базой пользователей и примерно 1.5-2к приходящих/уходящих пользователей в сутки из глобальной сети. Держит все это добро вот такое железо: 4xAMD Opteron Dual Core 2.2Ghz, 8Gb RAM, 600 Gb SATA RAID, OS - Win2k3 Server (возможен переход на Win2k8 Server в будущем).
Теперь программная часть. Объем данных в таблицах - десятки тысяч записей (ну ессесно растет), самих таблиц под сотню. "Тяжелые" (шаблоны, картинки и т.д.) данные встречаются всего в паре мест. Запросы не сложные, по большей части простые SELECT/INSERT/UPDATE'ы. После обновления часть повторяемых запросов будет вынесена в хранимые процедуры. Также будут использоваться транзакции и нормальная поддержка юникода (сейчас данные в кодировке latin1, планируется переход на utf8). Планируется организация репликации.

Лично я больше склоняюсь к MySQL 5.1. Про MSSQL, после прочтения этого топика, сложилось впечатление избыточности по сравнению с текущими нуждами. И в любом случае, мне кажется, что процесс обновления бд менее затратен, чем переход на новую.
Что подскажете, посоветуете?

Работает? - Не трогай! 

Не совсем понятно зачем:

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