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

Откуда:
Сообщений: 5824
vadiminfo
Ну это возможно какое-то сильное предположение, нуждающееся в дополнитекльных подтверждениях.


Каких?
Т.е. Вы считаете, что сложная система более надежна?

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


Возьмем например C и Delphi.
Например С дает полный контроль над системой.
Хотя "фич" там не очень много.
В Delphi же очень много фич, хотя контроль над системой она дает почти такой же как и C.

Тем не менее в общей массе программы на C более надежные, чем на Delphi.

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

vadiminfo
Понятие унивенрсал нуждается в некоторм уточнении. Однако, мы же видим, что если есть фича секционирования у СУБД, это не делает ее хуже тех СУБД у которых таковой нет, скорей всего. Т.е. добавление данной фичи, некоторые тут вроде даже приписывали своим СУБД, хотя их в последствии там не оказалось. Это делает, возможно, Вашу теорему о вредности фич по факту самого своего существования преждевременной. Более того, возможно, Вам следовало бы относиться с "настороженностью" к отсутсвию таковых.


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


vadiminfo
У Оракла, по крайней мере, проблем в инструменте по сравнению с другими СУБД вроде особо не обнаруживается.
А проблемы в проектировании могут оказаться у любого. Такие риски исключать было бы чрезмерно самонадеяно. А ЖЦ в общем случае может иметь модели не предполагающие на этапе выбора СУБД предвить все.


Т.е. принцип "большого швейцарского ножа".
Это не наш путь :-)
По мне, инструмент должен делать одну функцию, но хорошо! ;-)

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


Упс... а я не знал, что триггеры отменили.
А вызвать стороннее приложение из Oracle не возможно?! <:o)

vadiminfo
Это какой внешний? Как он узнает, что в ней что-то произошло? Запрос пошлет? Кажную секунду? Написаный проггерами или мессажер ОСи приспособить? Так оси разные могут быть. И прог много может быть.
Если СУБД файл-серверная, то типа и проигрывает. А клиентсевреная может тока запросы возвращать, которые юзеру клиент представляет. В том числе и фильмы. А так да у Оракла есть поддержка и мультимедиа.


У-у-у как все запущено.... <:o)
12 май 11, 15:57    [10642565]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
-2-
Member

Откуда:
Сообщений: 15330
mad_nazgul
Возьмем например C и Delphi.
Возьмем SQL и неСУБД...

mad_nazgul
Упс... а я не знал, что триггеры отменили.
DML event лишь частный случай события. К тому же триггер работает синхроннно в контексте самого события.
12 май 11, 17:53    [10643544]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
SERG1257
Member

Откуда:
Сообщений: 2931
2 vadiminfo
Не стоит метать бисер перед юношей бледным со взором горячим (с)

Ответ топикстартеру был дан Dimitry Sibiryakov остальное флуд.
13 май 11, 06:38    [10644968]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
-2-
Возьмем SQL и неСУБД...


Сравнивать имеет смысл подобное с подобным.
Например как вы сравните "СУБД" с "красным цветом" :-)

-2-
DML event лишь частный случай события. К тому же триггер работает синхроннно в контексте самого события.


Опять же я не знаю точной постановки задачи.
Но ставить себя в зависимость от реализации фич в инструменте...
Как минимум не дальновидно. :-)
13 май 11, 08:57    [10645007]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
SERG1257
2 vadiminfo
Не стоит метать бисер перед юношей бледным со взором горячим (с)
Ответ топикстартеру был дан Dimitry Sibiryakov остальное флуд.


Почему бы не по развлекаться если есть время. <:o)
13 май 11, 09:00    [10645013]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
mad_nazgul
Т.е. Вы считаете, что сложная система более надежна?

Вроде я про теорию надежности ниче не говорил.
Ну хорошо. Я считаю что сложный мерсидес надежнее простого шахидомобиля.
В плане надежности Оракл поборется: у него есть средства с фичами и для этих целей. И, в частности, поддержка резервные БД, что с точки зрения теории надежности и позволяет обеспечивать максимальную надежность. В частности можно организовать, что если сервак взорвется, то система продолжит работать.




mad_nazgul
Возьмем например C и Delphi.
Например С дает полный контроль над системой.
Хотя "фич" там не очень много.
В Delphi же очень много фич, хотя контроль над системой она дает почти такой же как и C.


Полный дает ассемблер.
Если сравнивать все же с СУБД, то тада проггеру полноный контроль дает не СУБД без фич, а вообще отказ от СУБД.



mad_nazgul
Тем не менее в общей массе программы на C более надежные, чем на Delphi.

Это в основном драйверы что ли?



Риски провалить проект (не уложиться в срок) или сделать его менее качественным или геморным ЖЦ системы на С для ИС, возможно, повыше, чем на Дельфи.

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

Заплатки налабанные проггерами для компенсации отсутсвующих фич СУБД выглядят как иллюзия "правильного пути". Хотя это конечно свой путь.

mad_nazgul

Не факт.
Введение секционирования - это перекладывания проблемы с создателя БД, на пользователя.

Вы о чем? Что перекладывается на пользователя? Он вообще не в курсах.
Вообще-то это решение физической проблемы производительности без влияния на логику. Т.е. это снятие с разработчика логического уровня физических проблем.

Запросы для секционированной таблицы те же, что и для обычной, но в ходе выполнения пропускаются не нужные секции.
Например, секции за разные года в разных файлах, а табла то одна. И если в запросе данные за 2010 год, то файлы за остальные сто лет считываться не будут. Пишуший запросы в общем случае вообще может не знать о том, что табла секционирована. Вы это называете перекладыванием проблемы? А я думал что это устранение проблемы легким движением руки.

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


mad_nazgul
Т.е. по факту мы не знаем как решить проблему, но предлагаем суррогат, который Вы можете использовать на свой страх и риск.

Вы то может и не знаете проблему. А у нас фича есть. Она все на раз разрулит без всяких страхов и рисков.

mad_nazgul


Т.е. принцип "большого швейцарского ножа".
Это не наш путь :-)
По мне, инструмент должен делать одну функцию, но хорошо! ;-)

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

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

mad_nazgul

Упс... а я не знал, что триггеры отменили.
А вызвать стороннее приложение из Oracle не возможно?! <:o)



И триггеры не отменили. И Oracle может вообще по мылу письма рассылать. Можно даже на виндовозном Оракле и программировать объекты Ворда, Йекселя (т.е. их запустить и заполнить данными из БД). Не говоря о выполнении запросов на своем диалекте SQL из других СУБД.
Вот тока, я думал, что для оповещения клиентких прог такая затычка с запуском сторонних прог выглядит чрезмерно не привлекательно. Это сторонне приложение на сервере буит обмениваться с клиентами во всей сети сообщениями? А када поступит новое сообщение запустится еще одна стороння прога? И так все 10000 раз? Впрочем, лабы по написанию прог взаимодействующих в сети луче оставить студентам.
Я раньше думал, что запуск стронних приложений для таких целей находится за гранью рассмотрения. Все же бомбление БД запросами через какждую сек выглядит, пожалуй, попривлекательнее: энтропия программного обеспечения поменьше буит. Впрочем, есть же любители фильмов ужасов.
mad_nazgul
Т.е. Вы считаете, что сложная система более надежна?

Вроде я про теорию надежности ниче не говорил.
Ну хорошо. Я допусекаю что сложный мерсидес надежнее простого шахидомобиля.
В плане надежности Оракл поборется: у него есть средства с фичами и для этих целей. И, в частности, поддержка резервные БД, что с точки зрения теории надежности и позволяет обеспечивать максимальную надежность. В частности можно организовать, что если сервак взорвется, то система продолжит работать.




mad_nazgul
Возьмем например C и Delphi.
Например С дает полный контроль над системой.
Хотя "фич" там не очень много.
В Delphi же очень много фич, хотя контроль над системой она дает почти такой же как и C.


Полный дает ассемблер.
Если сравнивать все же с СУБД, то тада проггеру полноный контроль дает не СУБД без фич, а вообще отказ от СУБД.



mad_nazgul
Тем не менее в общей массе программы на C более надежные, чем на Delphi.

Это в основном драйверы что ли?


Есче раз: в общем случае превзойти возможности СУБД класса Оракла в вопросах надежности не так просто. Причем основное делают фичи, потому разработчик не очень напрягается.

Зато риски провалить проект или сделать его менее качественным или геморным ЖЦ системы на С для ИС значительно выше, чем на Дельфи.

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

Заплатки налабанные проггерами для компенсации отсутсвующих фич СУБД выглядят как иллюзия "правильного пути". Хотя это конечно свой путь.

mad_nazgul

Не факт.
Введение секционирования - это перекладывания проблемы с создателя БД, на пользователя.

Вы о чем? Что перекладывается на пользователя? Он вообще не в курсах?
Вообще-то это решение физической проблемы производительности без влияния на логику. Т.ек. это снятие с разработчика логического уровня физических проблем.

Запросы для секционированной таблицы те же, что и без, но в ходе выполнения пропускаются не нужные секции.
Например секции за разные года в разных файлах, а табла то одна. И если в запросе данные за 2010 год, то файлы за остальные сто лет считываться не будут. Пишуший запросы в общем случае вообще может не знать о том, что табла секционирована. Вы это называете перекладыванием проблемы? А я думал что это устранение проблемы легким движением руки.

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


mad_nazgul
Т.е. по факту мы не знаем как решить проблему, но предлагаем суррогат, который Вы можете использовать на свой страх и риск.

Вы то может и не знаете проблему. А у нас фича есть. Она все на раз разрулит без всяких страхов и рисков.

mad_nazgul


Т.е. принцип "большого швейцарского ножа".
Это не наш путь :-)
По мне, инструмент должен делать одну функцию, но хорошо! ;-)

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

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

mad_nazgul

Упс... а я не знал, что триггеры отменили.
А вызвать стороннее приложение из Oracle не возможно?! <:o)



И триггеры не отменили. И Oracle может вообще по мылу письма рассылать. Можно даже на виндовозном Оракле и программировать объекты Ворда, Йекселя (т.е. их запустить и заполнить данными из БД). Не говоря о выполнении запросов на своем диалекте SQL из других СУБД.
Вот тока, я думал, что для оповещения клиентких прог такая затычка с запуском сторонних прог выглядит чрезмерно не привлекательно. Это сторонне приложение на сервере буит обмениваться с клиентами во всей сети сообщениями? А када поступит новое сообщение запустится еще одна стороння прога? И так все 10000 раз? Я думал, что запуск стронних приложений за гранью рассмотрения.
Я теперь совсем рад, что в Оракле есть такая фича: вдруг нашлись бы такие проггеры и в нашей фирме, которые налабали бы такого типа агента ( агентов). Может кто-то заинтересован налабать такое, чтобы других отпугивало.
13 май 11, 09:21    [10645087]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Ошибочно два раза скопировалось.
13 май 11, 09:24    [10645097]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
Орел в небе
Guest
Не надоело обсуждать, что круче Оракла только горы? Я давно усвоил две вещи:
1. Все, что есть в Оракле и в других СУБД, первым придумал Оракл.
2. Если в Оракле этого нет, значит это не нужно.

И с этим я полностью согласен. Это реалии современного рынка СУБД.
13 май 11, 09:49    [10645238]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
Sergey Orlov
Member

Откуда: СПб
Сообщений: 4508
vadiminfo
И триггеры не отменили. И Oracle может вообще по мылу письма рассылать. Можно даже на виндовозном Оракле и программировать объекты Ворда, Йекселя (т.е. их запустить и заполнить данными из БД). Не говоря о выполнении запросов на своем диалекте SQL из других СУБД.
Вот тока, я думал, что для оповещения клиентких прог такая затычка с запуском сторонних прог выглядит чрезмерно не привлекательно. Это сторонне приложение на сервере буит обмениваться с клиентами во всей сети сообщениями? А када поступит новое сообщение запустится еще одна стороння прога? И так все 10000 раз? Я думал, что запуск стронних приложений за гранью рассмотрения.
Я теперь совсем рад, что в Оракле есть такая фича: вдруг нашлись бы такие проггеры и в нашей фирме, которые налабали бы такого типа агента ( агентов). Может кто-то заинтересован налабать такое, чтобы других отпугивало.

Какая разница, запустить еще один процесс вызвав функцию из dll или запустить сторонную программу передав ей параметры...В последнем случае немного накладных расходов только побольше....
13 май 11, 09:55    [10645274]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
miwaonline
Member

Откуда:
Сообщений: 2249
Орел в небе
Не надоело обсуждать, что круче Оракла только горы? Я давно усвоил две вещи:
1. Все, что есть в Оракле и в других СУБД, первым придумал Оракл.
2. Если в Оракле этого нет, значит это не нужно.
И с этим я полностью согласен. Это реалии современного рынка СУБД.


А я - еще три
3. Если в Оракле этого нет, а друге используют - значит другие идиоты.
4. Если в Оракле это есть, а больше нигде (в том числе и в стандарте) нету, или реализовано/написано иначе - значит другие идиоты.
5. Если название СУБД не начинается на «Ор» и не заканчивается на «акл», значит это не СУБД, а тот кто утверджает обратное - идиот.
С этой темы винес еще одно
6. На базе в тыщу записей Постгрес будет тормозить, поэтому для нее нужен только Оракл.
И с этим я тоже полностью согласен. Это реалии современных форумов.

Простите, не удержался.
13 май 11, 10:33    [10645609]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
vadiminfo
Вроде я про теорию надежности ниче не говорил.
Ну хорошо. Я считаю что сложный мерсидес надежнее простого шахидомобиля.


Сложность должна быть "внутри".
Грубо говоря "инструмент" должен быть прост в использовании и не сложен в изучении.
Я бы провел аналогии мерседес - VB, шахмобиль - C <:o)

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


Повторю - фичи Oracle это из-за неспособности скрыть сложность (т.е. решить проблему).
Внутри инструмент может быть сколь угодно сложным, но снаружи он должен быть простым.
Вы же предлагаете, что инструмент должен быть сложным и снаружи и внутри. ;-)

vadiminfo
Полный дает ассемблер.
Если сравнивать все же с СУБД, то тада проггеру полноный контроль дает не СУБД без фич, а вообще отказ от СУБД.


Согласен.
Но СУБД как раз и предназначена скрыть сложность.
Вводя разумные ограничения.

vadiminfo
Это в основном драйверы что ли?



vadiminfo

Риски провалить проект (не уложиться в срок) или сделать его менее качественным или геморным ЖЦ системы на С для ИС, возможно, повыше, чем на Дельфи.


Да-да... "Мифический человеко-месяц" :-)
Просто видел я программы на Delphi выпущенные в срок...
Это феерическое зрелище. Напичканное "свистелками и перделками" по самое не хочу.
А фигли - фичи же.

vadiminfo

Заплатки налабанные проггерами для компенсации отсутсвующих фич СУБД выглядят как иллюзия "правильного пути". Хотя это конечно свой путь.


Зачем заплатки?
Есть готовые апробированные решения.
См "Unxi way"

vadiminfo

Вы о чем? Что перекладывается на пользователя? Он вообще не в курсах.
Вообще-то это решение физической проблемы производительности без влияния на логику. Т.е. это снятие с разработчика логического уровня физических проблем.


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

vadiminfo

Запросы для секционированной таблицы те же, что и для обычной, но в ходе выполнения пропускаются не нужные секции.
Например, секции за разные года в разных файлах, а табла то одна. И если в запросе данные за 2010 год, то файлы за остальные сто лет считываться не будут. Пишуший запросы в общем случае вообще может не знать о том, что табла секционирована. Вы это называете перекладыванием проблемы? А я думал что это устранение проблемы легким движением руки.


Вообще-то "фича" партицирования не должна "звучать".
Просто производительность СУБД стало лучше.
А вот уже планирование какое партицирование использовать в каких случаях и т.д. - это я называю взваливать проблемы на пользователя.

vadiminfo

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


Опять "динамическое" и т.д.
Вообще пользователь должен иметь просто набор данных (в таблицах) и способы манипулирования ими.
А вот как, когда и где их размещать/хранить и т.д. должен заботиться инструмент.


vadiminfo

Вы то может и не знаете проблему. А у нас фича есть. Она все на раз разрулит без всяких страхов и рисков.


Зачем нужна фича и способ ее управления?
Если Вы знаете проблему, то решите ее.
А так - есть проблема, но мы не знаем как ее решить.
Вот Вам фичи вы можете подкрутить так, а можете эдак.
Как нужно так и крутите.

Опять приходим к тому, что "цниверсал - это делает все одинаково плохо" :-)

vadiminfo

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


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


vadiminfo

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


О чем я и говорю.
СУБД должно работать только с данными.
Остальные вещи должны делать другие программы.


vadiminfo

И триггеры не отменили. И Oracle может вообще по мылу письма рассылать. Можно даже на виндовозном Оракле и
...
Впрочем, есть же любители фильмов ужасов.


Я же говорю - "Большой швейцарский нож".
Письма рассылает, может еще пусть и кино показывать умеет?
Фича же, вдруг пригодиться.

<:o)
13 май 11, 10:37    [10645637]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Sergey Orlov
Какая разница, запустить еще один процесс вызвав функцию из dll или запустить сторонную программу передав ей параметры...В последнем случае немного накладных расходов только побольше....

Вообще-то эта стороння программа или там ф-я dll еще должна искать в сети подписавшихся на события в БД клиентов. Эти клиенты должны ждать, наверное, сообщений от этой проги (обратный вызов).
Т.е. триггера и другие разработанные для этого объекты БД вместе с этой сторонней программой или ф-ей (ф-ями) из dll или еще откуда бы не было из вне, должны реализовывать механизм подписки клиентами на события в БД в сетях разого рода в общем случае. Ну для куросвых или дипломных работ создание подобного рода типа агентов может и имеет образовательный интерес. Но в продакшине это все же выглядит, скорей всего, как чрезмерная примочка к СУБД. Еще немного и своя система сообщений в ОСи получится.
13 май 11, 10:45    [10645707]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
vadiminfo
Вообще-то эта стороння программа или там ф-я dll еще должна искать в сети подписавшихся на события в БД клиентов. Эти клиенты должны ждать, наверное, сообщений от этой проги (обратный вызов).


Судя по описанию можно использовать либо почту, либо jabber.
13 май 11, 10:53    [10645777]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
-2-
Member

Откуда:
Сообщений: 15330
mad_nazgul
Сравнивать имеет смысл подобное с подобным.
И зачем тогда брать для сравнения язык программирования C и среду разработки Delphi, к которой, кстати, несложно прикрутить компиляцию С?
Если сравнивать сравнимое - какой такой контроль дает C по сравнению дельфевым паскалем?!
13 май 11, 10:56    [10645812]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
-2-
И зачем тогда брать для сравнения язык программирования C и среду разработки Delphi, к которой, кстати, несложно прикрутить компиляцию С?
Если сравнивать сравнимое - какой такой контроль дает C по сравнению дельфевым паскалем?!


Ну скажем Visual Studio C и Delphi :-)
13 май 11, 11:03    [10645879]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
mad_nazgul
Грубо говоря "инструмент" должен быть прост в использовании и не сложен в изучении.
Я бы провел аналогии мерседес - VB, шахмобиль - C <:o)


Повторю - фичи Oracle это из-за неспособности скрыть сложность (т.е. решить проблему).
Внутри инструмент может быть сколь угодно сложным, но снаружи он должен быть простым.
Вы же предлагаете, что инструмент должен быть сложным и снаружи и внутри. ;-)

Согласен.
Но СУБД как раз и предназначена скрыть сложность.
Вводя разумные ограничения.





Фичи и скрывают сложность. Написал простой запрос и вернул по ошибке снесенные данные. Сложности типа хде эти данные и все такое скрыты.

СУБД и предназначена для управления БД. И Фича и есть возможность достижения цели без особых усилий. Т.е. скрыть сложность на Вашем языке.


mad_nazgul
Зачем заплатки?
Есть готовые апробированные решения.
См "Unxi way"


Ну многие могут посмотреть и описание архитектуры самой СУБД. Но какда сами напишут ея, то это все равно во многих случаях галимые заплатки.
Так или иначе, скорей всего, смотрение "Unxi way" уже выглядит чем-то чрезмерным при проектировании ИС.

mad_nazgul


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


Вообще-то за него давно подумали применив фичу. Но хорошо, а кто у Вас думает что прикрутить вместо фичи, чтобы повысить производительность?


mad_nazgul


Вообще-то "фича" партицирования не должна "звучать".
Просто производительность СУБД стало лучше.
А вот уже планирование какое партицирование использовать в каких случаях и т.д. - это я называю взваливать проблемы на пользователя.



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


mad_nazgul
Опять "динамическое" и т.д.
Вообще пользователь должен иметь просто набор данных (в таблицах) и способы манипулирования ими.
А вот как, когда и где их размещать/хранить и т.д. должен заботиться инструмент.


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


mad_nazgul


Зачем нужна фича и способ ее управления?
Если Вы знаете проблему, то решите ее.
А так - есть проблема, но мы не знаем как ее решить.
Вот Вам фичи вы можете подкрутить так, а можете эдак.
Как нужно так и крутите.



Фича нужна, чтобы по легкому решить проблему. Ну решу с помощью фичи если таковая имеется.
А вот если нет фичи, то в некоторых случаях не известно как приемлемым способом: без чрезмерного гимора решать.
Вот я и кручу фичи.

mad_nazgul

Опять приходим к тому, что "цниверсал - это делает все одинаково плохо" :-)


Тока что Вы сказали, что СУБД должна быть по сути универсалом по отношению у управлению данными. Таепрь о том что универсал все делает плохо. Ну хорошо. Тада скажем так универасал в фичами менее плох, чем таковой без фич


mad_nazgul


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


Так и я о том же. СУБД должны делать профессионалы в разработке СУБД. ИС профессионалы в разработке ИС.
А Вы как бы занимаетесь вроде ИС, но не отрицаете доделываня приблуд к СУБД.

mad_nazgul


О чем я и говорю.
СУБД должно работать только с данными.
Остальные вещи должны делать другие программы.

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


mad_nazgul

Я же говорю - "Большой швейцарский нож".
Письма рассылает, может еще пусть и кино показывать умеет?
Фича же, вдруг пригодиться.

Файл серверная СУБД типа Аксцесс сделает это. А клиентсерверная может тока предоставить фичи по урпавления не структрированныими данными. Поддерживать мультимендиа. Там следить чтобы они были правильного формата.

Вы по сути все хорошо рассказываете о пользе фич, но их при этом отрицаете. Вот что сбивает с толку.
13 май 11, 11:34    [10646187]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
Dimitry Sibiryakov
Member

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

vadiminfo
В частности можно организовать, что если сервак взорвется, то система продолжит работать.

А вот отсюда поподробнее, пожалуйста: как продолжит работать система если взорвать Listener?

Posted via ActualForum NNTP Server 1.4

13 май 11, 12:00    [10646438]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Dimitry Sibiryakov
А вот отсюда поподробнее, пожалуйста: как продолжит работать система если взорвать Listener?

Ну я думау, что на резервном сервере, который в 200 метрах был на этот случай найдется не взорваный в силу удаленности Listener. А главное БД с актуальными данными (т.е. совпадающие с основным).
13 май 11, 12:05    [10646496]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
Dimitry Sibiryakov
Member

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

vadiminfo
Ну я думау, что на резервном сервере, который в 200 метрах был на этот случай найдется не
взорваный в силу удаленности Listener. А главное БД с актуальными данными (т.е.
совпадающие с основным).

А как клиенты узнают о существовании этого резервного Listener-а? Телепатически?

Posted via ActualForum NNTP Server 1.4

13 май 11, 12:21    [10646680]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
vadiminfo
Member

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

А как клиенты узнают о существовании этого резервного Listener-а? Телепатически?


А им и знать не надо. На то есть ДБА. Он может заранее в Листенере прописать в ТНСе. Там типа можено прописать, чтробы клиент пытался приконнектиться к какой получится: если не получилось к первой, пробует ко второй и т.д.. В РАК тоже он коннектится часто таким же способом, то к тому инстансу то к другому. А какая для сети разница инстансы одной БД или разных на разных серваках. Если используется резервный, то ДБА должен типа обявить его резервный основным. Если мультимастер репликация, то юзер мог и до часа Х коннектиться то к тому то к другому - для него вообще не заметно потери бойца.
13 май 11, 12:35    [10646799]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
-2-
Member

Откуда:
Сообщений: 15330
mad_nazgul
Ну скажем Visual Studio C и Delphi :-)
И как среда разработки может ограничить "контроль над системой"?
13 май 11, 12:53    [10646929]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Dimitry Sibiryakov
vadiminfo
В частности можно организовать, что если сервак взорвется, то система продолжит работать.

А вот отсюда поподробнее, пожалуйста: как продолжит работать система если взорвать Listener?


Есть такая фича как клиентский Failover на Standby сервер.
Странно, что Вы не в курсе :)

В принципе :) никто не мешает реализовать ее и руками
13 май 11, 14:01    [10647586]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
Dimitry Sibiryakov
Member

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

vadiminfo
Если мультимастер репликация, то юзер мог и до часа Х коннектиться то к тому то к другому
- для него вообще не заметно потери бойца.

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

Posted via ActualForum NNTP Server 1.4

13 май 11, 14:09    [10647666]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Dimitry Sibiryakov
vadiminfo
Если мультимастер репликация, то юзер мог и до часа Х коннектиться то к тому то к другому
- для него вообще не заметно потери бойца.

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


Standby друг !!! Никто ничего не теряет :)
Кроме некоторой просадки производительности при передаче REDO логов
13 май 11, 14:14    [10647722]     Ответить | Цитировать Сообщить модератору
 Re: СУБД что выбрать.  [new]
vadiminfo
Member

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

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

Ну уж извените. Какая мультимастер репликация. В синхронной не потеряется. В асинхронной мож и потеряется в пределах нескольких секунд.
13 май 11, 14:22    [10647814]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить