Никто не говорил, что PL/SQL менее надежен.
Просто применяются немного иные алгоритмы работы.
Можно например иметь тестовый сервер и прочие решения.
Суть в том, что это не проблемы если их можно решить.
Когда приложение не отвечает на запросы,
тут дисциплиной разработчиков например ничего не добьешься.
И вот это действительно проблема когда не хватает производительности.
Частично.
Некоторые вызовы делаются целиком на стороне БД, и могут вызываться откуда угодно.
Есть еще такая штука, как целостность данных в данном контексте, которая на стороне БД имеет больше шансов на успех.
Всякие банки и тот же билинг критичны к ним.
Это у вас не хватает опыта серьезных проектов и вы начитавшись умных книжек говорите про то, как важно
соблюдать цикл разработки, и какие вы тут все крутые программисты.
Как у вас красиво деплоится и генерируется код.
В реальной жизни, когда вы столкнетесь с серьезным проектом, когда несколько десятков терабайт текстовой информации нужны здесь и сейчас, все меняется.
И количества программистов, а главное качества, начинает резко не хватать.
О чем и речь, такое ощущение, что господа не имеют опыта работы.
Дело не только в переносимости, когда речь заходит о производительности, разница которого измеряется порядками.
1. Но мы помним, что язык SQL не так универсален в современном мире? И как минимум небольшой вендор-локин у нас в любом случае.
В частности различные подсказки для оптимизатора, такие вещи как партиционирование и т. д.
В любом случае не получится перенести серьезное приложение без переписывания кода.
2. В каком месте неохотно масштабируется, на реальных вещах если можно?
Глупости, это не учитывать перспективу времени, по отношению к железу в ИТ.
Сейчас в тренд врываются и будут господствовать планки по 32ГБ.
Сейчас они конечно стоят неподъемно, но еще чуть-чуть и устаканится.
Мат. плата с 32 планками стоит 20к. руб.
Да, 2 процессора, самых слабых ничего не мешает туда воткнуть.
>>Тем более, как вы собрались получить доступ к памяти по FC или SAS?
На стороне нашего сторэджа, из памяти, делается блочное стройство.
На линуксе это делается штатными средствами.
Проблема питания в нашем веке успешно решает УПС.
К тому же, вы проглядели flashcache.
Возможностей масса.
Дело не в этом. Просто это не энтерпрайзно как скажут многие.
Вы вообще знаете из чего делается железо СХД многих известных вендоров, к примеру IBM?
Взять слабенький сервер натыканый 1ТБ памяти, поставить его рядом с рабочим сервером.
По идее их можно соединить через FC или SAS и получить значительно более быструю СХД.
На этом же сервере независимо можно настроить бэкап из памяти уже на ХДД, или настроить flashcache.
А Terradata, это тот же самый vendor lock-in, а так же куча других минусов с ним связанных.
Но суть в том, что все что вы описали и Oracle DB имеют радикально разные предназначения.
Никто не говорил, что PL/SQL менее надежен.
Просто применяются немного иные алгоритмы работы.
Можно например иметь тестовый сервер и прочие решения.
Суть в том, что это не проблемы если их можно решить.
Когда приложение не отвечает на запросы,
тут дисциплиной разработчиков например ничего не добьешься.
И вот это действительно проблема когда не хватает производительности.
Вы прикалываетесь?
Здесь речь идет в контексте полного ухода от оракла и/или оракл не панацея.
Покупка Экзадаты это конечно не vendor lock-in и прочее, прочее говно с ним связанное.
Некоторые вызовы делаются целиком на стороне БД, и могут вызываться откуда угодно.
Есть еще такая штука, как целостность данных в данном контексте, которая на стороне БД имеет больше шансов на успех.
Всякие банки и тот же билинг критичны к ним.
соблюдать цикл разработки, и какие вы тут все крутые программисты.
Как у вас красиво деплоится и генерируется код.
В реальной жизни, когда вы столкнетесь с серьезным проектом, когда несколько десятков терабайт текстовой информации нужны здесь и сейчас, все меняется.
И количества программистов, а главное качества, начинает резко не хватать.
А пока да, производительность на втором месте.
Конкретно, в чем проблема версионирования и хранения исходников PL/SQL или какого-нибудь другого хранимого кода?
Дело не только в переносимости, когда речь заходит о производительности, разница которого измеряется порядками.
Не понял, PL/SQL по вашему имеет отношение к DBA?
Я такого не видел.
В частности различные подсказки для оптимизатора, такие вещи как партиционирование и т. д.
В любом случае не получится перенести серьезное приложение без переписывания кода.
2. В каком месте неохотно масштабируется, на реальных вещах если можно?
А чем объективно плоха бизнес-логика на стороне БД?
Недвано смотрел видео, где рассказывалось про совместимость с обычными кабелями.
Но ничего не поделать.
И что с USB-OTG?
крестfuck. ))С установленным линуксом.
Вполне себе mid-range СХД.
Здесь мы реализовавываем то же самое, только вместо дисков на той стороне, мы имеем здоровенную оперативку и диски произвольного объема.
>> " обрабатываться они будут сколько?"
Вы имеете в виду скулевым сервером или что?
>>Для примера кэшу ещё нужно разогеться
Ну так он будет разогреваться на старте системы.
Сейчас в тренд врываются и будут господствовать планки по 32ГБ.
Сейчас они конечно стоят неподъемно, но еще чуть-чуть и устаканится.
Мат. плата с 32 планками стоит 20к. руб.
Да, 2 процессора, самых слабых ничего не мешает туда воткнуть.
>>Тем более, как вы собрались получить доступ к памяти по FC или SAS?
На стороне нашего сторэджа, из памяти, делается блочное стройство.
На линуксе это делается штатными средствами.
Проблема питания в нашем веке успешно решает УПС.
К тому же, вы проглядели flashcache.
Возможностей масса.
Дело не в этом. Просто это не энтерпрайзно как скажут многие.
Вы вообще знаете из чего делается железо СХД многих известных вендоров, к примеру IBM?
По идее их можно соединить через FC или SAS и получить значительно более быструю СХД.
На этом же сервере независимо можно настроить бэкап из памяти уже на ХДД, или настроить flashcache.
После N900, очень не хватало.