Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Нет нужды изучать конкретную СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
джиммерс
Ну почему глупости - может кто-то аргументирует такую точку зрения.

Аргументировать ее - Ваша забота (как заявившего ее).

джиммерс
Кроме того, человек весьма уважаемый,

"Широко известный в узких кругах"?

джиммерс
так что не стОит так резко.

Пока что этот уважаемый человек (в Вашем исполнении) не сказал ничего, что выдерживало бы минимальную критику.
18 ноя 04, 16:56    [1117837]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
джиммерс
Member

Откуда:
Сообщений: 216
Вот так, ссаными тряпками... :)
18 ноя 04, 17:13    [1117969]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Тут коллега высказал интересный тезис: программисту нет нужды знакомиться с нюансами реализации той или иной СУБД, будь то MSSQL, Oracle. Это, дескать, задача администратора – подкручивать всё для оптимизации производительности.

Тезис ложный. Администратор не имеет право менять код запросов. Многие сложные запросы без изменения кода запроса оптимизировать невозможно.
Человек, который так говорит - последний ламер в СУБД.

А разработчику достаточно знать стандарт SQL92 и вперёд.

Стандарт большинством поддерживается только на entry level. На нем много
не напишешь.

В частности, хранимые процедуры коллега не использует в принципе и говорит, что написанный им код (работающий с базой) совместим с практически любой СУБД.

Либо этот код никогда реально не работал, либо это тривиальнейшие запросы типа INSERT/UPDATE/DELETE/SELECT одной записи. Либо он просто врет или выдает желаемое за действительное.

P.S. Коллега – java developer и, судя по его словам, уже 10 лет придерживается такого подхода.

Странно, как он с таким подходом продержался так долго.

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

Как аргумент для тебя - самое простое.
Создавая БД нужно четко представлять системы типов и доменов, предоставляемые конретной СУБД (набор типов данных, возможности создавать пользовательские типы, допустимые диапазоны значений, определенные операции с каждым из типов).
Это - основы СУБД, но у всех СУБД системы типов данных разные, только базовые типы данных есть в entry level стандарта, а все остальные типы являются как правило расширениями конкретных СУБД.
26 ноя 04, 12:34    [1138358]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Кстати , еще скажу.
В настоящее время стандарт SQL ничего практически не определяет.
Поэтому нет переносимых баз данных, и нет универсального SQL.
С другой стороны, если бы было так, то у нас был бы только один большой сервер СУБД (назывался бы он, естественно, ORACLE), и был бы далеко не самым лучшим. Конкуренция была бы убита на корню.
26 ноя 04, 12:39    [1138387]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
MasterZiv
Поэтому нет переносимых баз данных, и нет универсального SQL. С другой стороны, если бы было так, то у нас был бы только один большой сервер СУБД (назывался бы он, естественно, ORACLE), и был бы далеко не самым лучшим. Конкуренция была бы убита на корню.

Думаю, все было бы несколько хуже. Есть очень близкий пример - язык C. Это именно тот случай, когда насильно и быстро приводили к стандарту множество различных реализаций де-факто.

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

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

Соответственно, к аккуратному, планомерному, продуманному стандартизированию я отношусь хорошо. А к идее "быстро все на стандарт и будет щастье" - крайне отрицательно.
26 ноя 04, 14:30    [1139008]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
Guest_New
Guest
Может я не в тему...
У SUN есть стандарт JDO. Вроде его реализации позволяют переключатся между различными SQL-серверами. Или я не о том?
26 ноя 04, 17:42    [1140045]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
Guest_New
Guest
Может я не в тему...
У SUN есть стандарт JDO. Вроде его реализации позволяют переключатся между различными SQL-серверами. Или я не о том?
26 ноя 04, 17:43    [1140047]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
Yo!
Guest
автор
У SUN есть стандарт JDO. Вроде его реализации позволяют переключатся между различными SQL-серверами. Или я не о том?


не все сейчас готовы за это платить скоростью ... однако прогресс железа все же опережает апетиты жабы, оракл уже крутят дома на игровых писюках ...
26 ноя 04, 17:54    [1140092]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
tru55
Member

Откуда: СПб
Сообщений: 19788
задача администратора – подкручивать всё для оптимизации производительности

Свои две копейки

У Oracle в концепциях настройки производительности первым пунктом идет оптимизация ПРИЛОЖЕНИЙ. Т.е. они считают, что такая настройка дает наибольший эффект. А остальной настройкой надо заниматься уже после этого первого пункта. Так что.....
26 ноя 04, 18:27    [1140207]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
hgst
Guest
Забавно...
Интересно, откуда берется такой максимализм в высказываниях. Создается такое впечатление что почти все высказавшиеся ворочают базами от террабайта и выше и решают задачи где задержка в 1-2 микросекунды просто страшно подумать к чему приведет. :) Или, по крайней мере, считают что почти все БД в мире именно в таком режиме и должны работать.

Правда, имхо, как обычно, где-то все же посередине.

Есть смутное подозрение что для большинства баз (я не утверждаю что для всех :) ), абсолютно все равно полезут к ним через специализированный язык сервера или через какой-либо промежуточный объектный уровень вроде EJB, Hibernate, JDO и т.д.

Для заказчика, в общем, важно чтобы работало быстро (и сейчас и с учетом роста базы), а не еще быстрее... ("мы и не говорили что вы будете жить хорошо, мы всегда говорили что вы будете жить еще лучше..." (c) сами знаете кто).

Тред чем-то напоминает аналогичные годов 80-90 ASM ws С/C++ - приходили к нормальному здравому решению - критические участки писались на asm, основная масса на C. С БД тоже, кстати, видел подобные решения (по правилу 80/20 :) ) и все это без проблем работает.

Если же смотреть с точки зрения рынка ПО... Нужно подумать. Выигрыш в скорости разработки при использовании подобных средств очень большой. Соответственно оценка времени на реализацию проекта и его стоимость для заказчика будет ниже. Соответственно...

Имно, если присутствует критерий для БД: настолько быстро насколько возможно, то это подход не пройдет. Но в большинстве случаев обычно есть что-то вроде "время выполнения транзакции XXX должно укладываться в ...". А в этом случае (само собой, после соответствующего тестирования и оценки с учетом роста базы на ближайшие n лет) решение на базе универсальных средств доступа оказывается более чем приемлемым.
4 дек 04, 01:24    [1157880]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Интересно, откуда берется такой максимализм в высказываниях.

Из опыта.

задержка в 1-2 микросекунды просто страшно подумать к чему приведет

Если речь идет о СУБД, там время выполнения запроса начинается от
милисекунд. Микросекунды - это очень мало.

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

А что, еще как-то к серверу можно "лезть" ? Вроде бы нет.

или через какой-либо промежуточный объектный уровень вроде EJB, Hibernate, JDO

Ну и ? Последный все равно на SQL будет к серверу обращаться.

Тред чем-то напоминает аналогичные годов 80-90 ASM ws С/C++ - приходили к нормальному здравому решению - критические участки писались на asm, основная масса на C. С БД тоже, кстати, видел подобные решения (по правилу 80/20 :) ) и все это без проблем работает.

Вот именно, SQL - это как ASM , он непереносим на другую платформу.
6 дек 04, 14:06    [1160325]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
hgst
Есть смутное подозрение что для большинства баз (я не утверждаю что для всех :) ), абсолютно все равно полезут к ним через специализированный язык сервера или через какой-либо промежуточный объектный уровень вроде EJB, Hibernate, JDO и т.д.

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

hgst
Для заказчика, в общем, важно чтобы работало быстро (и сейчас и с учетом роста базы), а не еще быстрее...

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

hgst
Тред чем-то напоминает аналогичные годов 80-90 ASM ws С/C++ - приходили к нормальному здравому решению - критические участки писались на asm,

Не совсем. Выбор asm/C - прикладной, не архитектурный. Вариант "реализовать все на C, потом критические участки переписать на ASM" разумен и хорошо работает; то же в случае специфики БД работает далеко не всегда. Проблема в том, что в случае БД есть большой разделяемый ресурс - сама БД - и любое неудачное решение может "выстрелить" во всех других местах, затормозить все, в том числе нормальные сами по себе фрагменты.

hgst
основная масса на C. С БД тоже, кстати, видел подобные решения (по правилу 80/20 :) ) и все это без проблем работает.

Полностью согласен и считаю это грамотным решением. Но чтобы это решение работало - надо представлять требования, возможности и ограничения сервера до начала кодирования. Иначе окажется, что заставить работать можно только превратив 80/20 в 10/90.

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

Согласен. Но - после соответствующей оценки, выполненных грамотными людьми. В ситуации начала разговора - "не собираюсь учить, поскольку не потребуется" - подход несколько другой и прогнозируемые результаты - соответствуют.
6 дек 04, 14:25    [1160392]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
Ярила
Member

Откуда: Москва
Сообщений: 10
автор, а может быть все-таки фраза поста вырвана из контекста и искажена?!
слышал я от знающих людей, что серверы приложений на то теоретически и нацелены - чтобы СУБД выполняло самые простые функции хранения и доступа к данным. А все остальное - ссылочная целостность и т.д. и т.п. переносится с тригггеерров и ХР на сервер приложений.
судя по тому, что товарищь с Явой работает, это и имелось в виду.имхо, канешн.
и все таки сдается мне, факты сильно перевраны!
11 дек 04, 05:25    [1175910]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Напиши на Java вычитание двух таблиц по ключу, а потом поговорим про то, кто будет выполнять только "самые простые функции хранения и доступа к данным". Да и ссылочная целостность базы данных, знаешь ли, не похоже, чтобы была б естественной функцией сервера приложений.
14 дек 04, 11:09    [1178879]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
Ярила
слышал я от знающих людей, что серверы приложений на то теоретически и нацелены - чтобы СУБД выполняло самые простые функции хранения и доступа к данным.

Не люблю говорить за глаза - но похоже, это знающие люди как раз того уровня, что "трудно изучить чужой велосипед - гораздо интереснее и занимательнее написать собственный".
14 дек 04, 11:48    [1179070]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
jimmers
Member

Откуда: Санкт-Петербург - New York City
Сообщений: 5072
Да, в общем-то всё понятно. Единственное, что подкачало, так это аргументация. Для себя-то я давно решил, а вот для товарища я порекомендую соответствующую главу из книги Тома Кайта Expert One-on-One Oracle.
14 дек 04, 17:16    [1180672]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
jimmers
Да, в общем-то всё понятно. Единственное, что подкачало, так это аргументация.

Каков вопрос - таков ответ. Например, парой писем выше именно на Кайта я и сослался. Просто потому, что собеседник проявил несколько другой подход к делу.
14 дек 04, 17:40    [1180760]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
hgst
Guest
softwarer
Каков вопрос - таков ответ. Например, парой писем выше именно на Кайта я и сослался. Просто потому, что собеседник проявил несколько другой подход к делу.

Извините за некоторую задержку с ответом. Все же отыскать пдф Тома Кайта требует некоторого времени, да и полистать тоже (как-никак ~1500 страниц) :). По примерам которые он приводит в начале книги:
Пример первый. Ключевой момент здесь "Для обеспечения повторяемости при чтении в Oracle не нужно использовать SELECT FOR UPDATE — это делается только для обеспечения последовательного доступа к данным.К сожалению,использованное разработчиками инструментальное средство это не учитывало — оно было создано для использования с другой СУБД, где именно так повторяемость при чтении и достигалась." Сложно тут что-либо сказать :) - давайте возьмем кривые средства разработки, сделаем на них криво, а затем будем утверждать что и весь подход кривой. :) несерьезно... Да - задача фреймворка закрыть от кодера детали реализации чего-либо. Но если фреймворк выбран криво - это не только к проблемам с БД приведет.
Пример второй. Он посложнее первого. Том специалист в своей области и решил его на уровне БД. Замечательно, но это просто одно из возможных решений. Детали в книге, конечно, не расписываюся, но, глядя просто на проблему как она описана - она на порядок быстрее решается именно на уровне App сервера. Она решается простой организацией пула потоков и пишется это, ну если уж очень лень, в течении одного, двух дней. При этом нет никаких проблем ни с организацией ID для отдельных транзакций ни остальных им описанных. Этот пример с таким же успехом можно приводить с оглавлением "как не надо писать на Java" :), точно так же как первую под названием что-либо в духе "как не надо выбирать средства для разработки". :)
15 дек 04, 01:28    [1181412]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
jimmers
Member

Откуда: Санкт-Петербург - New York City
Сообщений: 5072
hgst
Все же отыскать пдф Тома Кайта требует некоторого времени, да и полистать тоже (как-никак ~1500 страниц) :).


OFFTOPIC:

У вас PDF оригинального Кайта (англ)? Не поделитесь, если так?

Спасибо
15 дек 04, 05:34    [1181448]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
hgst
Guest
Оригинала нет - у меня перевод (рус). Если подойдет...
15 дек 04, 11:17    [1181981]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
hgst
Сложно тут что-либо сказать :) - давайте возьмем кривые средства разработки, сделаем на них криво, а затем будем утверждать что и весь подход кривой. :) несерьезно...

А зачем Вы приписываете то, чего никто не говорил?

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

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

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

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

hgst
При этом нет никаких проблем ни с организацией ID для отдельных транзакций ни остальных им описанных. Этот пример с таким же успехом можно приводить с оглавлением "как не надо писать на Java" :), точно так же как первую под названием что-либо в духе "как не надо выбирать средства для разработки". :)

Так именно об этом речь и идет - о том, что избежать применения мозгов не удастся, даже программируя СУБД на Java. Именно это хотел показать Том, и на это ссылался я.
15 дек 04, 11:30    [1182036]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Забавно наблюдать спор, которому по меньшей мере лет 20.
А именно конфликт разработчиков на ОО языках (таких как Java) и разработчиков реляционных БД.
Просвещаю: как результат этого спора появились объектные базы данных. И вот при использовании именно этих баз правы оказываются программисты, ориентирующиеся на ОО парадигму и отказ от SQL и хранимых процедур, а при использовании традиционных реляционных систем обычно побеждают уже приведенные здесь аргументы (имеется ввиду критика решений на Java).
Что же касается быстродействия, то уверяю вас, существуют задачи, которые будучи изначально решены на Java с использованием JDO и ООСУБД (типа FastObjects) будут на порядок быстрее ЛЮБЫХ решений с реляционными системами. Они просто по своей природе лучше решаются именно в рамках такой модели, а реляционные базы и SQL-запросы для них только лишняя работа и вычислительная нагрузка.
15 дек 04, 20:12    [1184004]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
hgst
Guest
softwarer
А зачем Вы приписываете то, чего никто не говорил?

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

hgst
Полагаю, Вы не совсем врубились в пример. MTS - это и есть, по сути, пул соединений. Перенеся пул на более ранний этап, получились бы те же самое тормоза - просто не на запросе к БД, а на "ждите ответа от сервера".

Почему же, Том вполне понятно пишет. Но ThreadPool != ConnectionPool, а я говорил именно о первом. В книге берется связка MTS режим сервера + AQ, приложению генерируется синтезированный id транзакции, чтобы не ожидать завершения задачи и все транзакции идут асинхронно. Пул потоков (не сессий) решает эту проблему на стороне сервера приложений приблизительно в этом же ключе, просто он проще и не зависит от БД. + если вам нужно вы можете пустить на нем короткие транзакции с синхронном режиме, а длительные в асинхронном. Это просто еще одно решение.

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

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

Поэтому, слова Тома "в команде разработчиков должно быть ядро "программистов базы данных",обеспечивающих согласованность логики работы с базой данных и настройку производительности системы." - это зачастую из разряда НФ. Вторая часть (первая в книге) - "успех или неудача разработки приложения базы данных (приложения,зависящего от базы данных)определяется тем, как оно использует базу данных;" - зависит от многих факторов и БД лишь один из них.
Мозги должны быть хотя бы у части людей на проекте - вот с этим абсолютно согласен :)
15 дек 04, 23:28    [1184163]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>> Что же касается быстродействия, то уверяю вас, существуют задачи, которые будучи изначально решены на Java с использованием JDO и ООСУБД (типа FastObjects) будут на порядок быстрее ЛЮБЫХ решений с реляционными системами.

Ну приводите тогда, либо пример задач, либо доказательство существования (и неединственности).
16 дек 04, 09:03    [1184416]     Ответить | Цитировать Сообщить модератору
 Re: Нет нужды изучать конкретную СУБД  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
Не существуют задач, которые будучи изначально решены на Java с использованием JDO и ООСУБД (типа FastObjects) были бы на порядок быстрее ЛЮБЫХ решений с реляционными системами.
16 дек 04, 09:09    [1184422]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить