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

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


В моем понимании фича - это "дополнительная" кнопка на "баяне". ;-)

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


Как раз принцип "Большого швейцарского ножа" приводит к большим не поворотливым ИС, которые трудно сопровождать.

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


Я не говорю, что ее не должно быть.
Я говорю, что "кнопок" должно быть меньше. ;-)


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


Угу нам нравиться "Баян", ведь в нем много "кнопок"!
<:o)

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


"фича" = "кнопка".
Я не против, если СУБД сама позаботиться о своей производительности.
Но если для этого что-то надо "тюнинговать", значит инструмент не идеален. ;-)

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


Об этом и речь.
Производитель инструмента не может/хочет решить проблему, поэтому дает потребителю дает "напильники" типа допили до нужного состояния. ;-)

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


СУБД - это не универсал.
Она должна быть заточена только под управление и манипулирование данными.
Причем "внутри" она может быть очень сложной.
Но "снаружи" должен быть простой интерфейс для управления. ;-)



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


Которые дают Вам (DBA) кучу "кнопок", типа если возникнут проблемы попробуйте их по нажимать ;-)
Кроме того, я не считаю что нужно разрабатывать самостоятельно какие-то приблуды, а наоборот использовать другие специализированные инструменты, которые решают определенные задачи. (см. Unix-way) ;-)


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


Рассылка "спама" это не задача СУБД ;-)


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

Вообще-то Аксцесс не умеет воспроизводить мультимедия файлы, но может.
Воспользовавшись Windows Media.
Т.е. воспользовавшись специализированной программой. ;-)

-2-mad_nazgulНу скажем Visual Studio C и Delphi :-)И как среда разработки может ограничить "контроль над системой"?

Да прошу прощения Microsoft C + Visual Studio и Delphi.
Т.к. Delphi это не только среда разработки, но и реализация языка (Object Pascal)

vadiminfoТ.е. если нет например фичи по секционированию, все работает медленно, сопровождать легче, чем с секционированием? Где секции настроил, все стало летать и забыл?


А если настроил не правильно и "летать" стало медленнее.

vadiminfoНу если отказаться от СУБД совсем, то их и вовсе не буит.


А куда оно денется?!
Как-то без "партицирования" СУБД жили лет двадцать ;-)

vadiminfoТ.е. Вы хотите сказать что Ваш инструмент без секционирования, сделает ОРАКЛа с секциями на мегатоннах данных?
Вас тада давно ждут с этим инструментом на TPC тестах.


Нет. Этого я не хочу сказать.
Я хочу сказать другое.
Сложность в реализации производительности должна быть "внутри", в идеале без какого-либо управления.
Т.е. пользователь должен думать только как манипулировать данными, а об производительности должна думать СУБД ;-)

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


Во!
Вы начинаете понимать.
БДА - это вынужденная фигура из-за несовершенства инструмента. ;-)


vadiminfoуниверсал по управлению и манипулированию БД.


Не я бы сказал односторонний специалист.
Делает одну вещь, но очень хорошо!

vadiminfoНу хорошо. ФИчи внутри сложные, но простые "снаружи".


Фичи как раз сложные и внутри и снаружи.
Чем больше "кнопок", тем сложнее инструмент. ;-)

vadiminfoДа поробуем нажать. А вот замена кнопок самостоятельно написанными (приблуды) приблудами вызывает обеспокоенность.


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

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


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


vadiminfoА это не важно. Оракл да и другие СУБД скупают многие решения. Это их дела. Для юзера СУБД - это все СУБД делает, а не какая-то там кривая самодека, наспех налабанная.

Это как раз важно!
СУБД не должна быть "швейцарским ножом".
Да и самому что-то дописывать в СУБД не надо.
Надо просто использовать уже готовые инструменты. ;-)

Gluk (Kazan)Ага, а когда то жили без СУБД. И без компьютеров.
И ничо так, строили себе пирамиды ...
Терабайтные объемы данных, панимаишь, тогда были еще не у каждого второго, да и с ручным партиционированием городили (кому надо было конечно) кто во что горазд.
А так таки согласен, жили :)

Ага, а теперь поговорим о скоростях дисковых массивах и скорости работы ЦП ;-)

Gluk (Kazan)Какие бы они у тебя не были (кстати, ЦП в данном случае ничего не решает), FullScan по терабайту ты ждать устанешь. А вот если его попилить на секции, скажем по 10 гигов, то дождаться какого нибудь отчетика за месяц требующего FullScan становиться уже реально.
Странно (чессслово) что это приходится объяcнять

А теперь вспоминаем что было 20 лет назад ;-)
Не лучше 30...
Тогда объемы данных были не на много меньше.
А проблемы с производительностью были гораздо сильнее.
И решались они просто - покупкой соответствующего дискового массива.
Т.к. проблема производительности дискового массива, это не проблема СУБД ;-)

vadiminfoКада медленно работает, луче не настраивать совсем, чтобы хуже не было?

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


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

vadiminfoТам речь шла о фичах вообще. А без фич не жили еще не разу. Ну мож ТЖ7 или там поделки какие. У кого их меньше у кого больше. Ну развек что без СУБД совсем жили.


Так ведь не от хорошей жизни. :-)
Поэтому для меня "фича" - это признания производителя инструмента, что он не знает как решить проблему. ;-)


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


Причем тут ИИ?
Просто инструмент обязан "скрывать сложность".
А то Oracle уже хочет свою ОС запилить для работы со своей БД ;-)
"Большой швейцарский нож".
Я думаю в "пределе" им нужно разрабатывать свой интерент, со всей программной и аппаратной инфраструктурой. ;-)


vadiminfoНет не начинаю понимать что Вы предлагаете. Отказаться от ДБА? И че буит? Фичи то у СУБД нет заменить ДБА. А в будующем может и самые СУБД исчезнут, роботы со знаниями в голове придут. Че об этом тут говорить?


Вот именно фичи, т.е. "кнопки".
Чтобы нажимать на кнопки нужен "боянист" (ДБА)
А людям не "боянист" нужен, а музыку послушать (например магнитофон сам-то) ;-)


vadiminfoВообще-то у управления данными много вещей в силу природы вещей.


Читаем Кода, Дейкстру и пр. классиков до просветления. ;-)


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


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


vadiminfoНу так и о том же. Использовать СУБД с его фичами, чтобы управлять данными. Чет-то не понятно. Вы че хотите фичи СУБД заменить "готовыми специализированными инструментами"? Которые будут, например, секционированием в БД заниматься?


Ага.
Вообще-то производительностью дисковой подсистемы должны заниматься фирмы выпускающие дисковые массивы. ;-)

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


А кто еще?
Или Вы хотите, чтобы Вам хлеб продавал лично пекарь?! ;-)

vadiminfoВот я и предпочитаю использовать по управлению данными готовый инструмент СУБД. А другие инструменты для управления данными, например, пусть юзают те у кого СУБД заточка.

А если его нет?
А надо.
Будете ждать пока в СУБД добавят фичу?!
<:o)