В других СУБД есть понятие отложенной перестройки индекса, т.е. вы данные модифицируете, но индекс при этом не пересчитывается.
Обычно используется при BULK insert.
Но чаще — как правило по умолчанию — индекс перестраивается немедленно при изменении данных.
И на это серверу просто необходимо потратить дополнительное время.
Какая стратегия постройки индекса была использована вами?
IMHO:
Выборка по первичному ключу должна происходить мгновенно, а не за 1,5 с. и даже не за 0,1 с.
Все приведённые цифры теста для меня слишком велики даже с поправкой на железо и VM, а потому сомнительны.
Так вот, как это называется)
Боюсь после такого откровения, ребёнок не захочет слушать сказки в моём исполнении.
Если представить, что на земле был бы только один человек, смог бы он себя познать до нашего уровня познания, имея в наличии только себя для исследования?
А главное — захотел бы?
Разговор почему-то плавно перетёк от человека (создателя) к процессорам (творению).
Историю про барона Мюнхаузена — как он сам себя из болота вытаскивал — помните?
Как вы думаете, остается ли при этом вариант случайного создания?
Оставьте в ангаре детали и приходите через надцать тысяч миллиардов лет за готовым СУ 35.
В идеале, конечно, было бы неплохо и детали не оставлять: а вдруг не те окажутся?
Сложность СУ 35 и человека несопоставимы.
Полностью с Вами согласен.
Ожидать от ИИ любви, жалости, жертвенности, любопытства и т.п. — всего того, что присуще живым существам — не приходится.
Ответ чувствует каждый из нас. Может быть не знает, но чувствует.
Вы бы не могли уточнить каким именно на Ваш взгляд органом чувств (глаз, ухо, ...) мы это чувствуем?
А то здесь уверяют, что это не более чем просто «определённые механизмы мозга».
Использовать СУБД, поддерживающую одновременно NoSQL+SQL+ООП интерфейсы, как внутри (для хранимых процедур) так и снаружи (С#, Java, Delphi, node.js, ...).
Вообще, суть немного в другом. XDBC позволяет делать динамические ХП, а Caché из коробки при NoSQL-доступе к данным — нет. И статья как раз о том, как обойти это ограничение.
Мной изначально предполагалось, что Вы как-то учтёте в конкретном предложении статьи сделанное уточнение.
Взглянув на сигнатуру хранимой процедуры, не вызывая её, я могу (должен) определить набор входных/выходных параметров.
Конкретно для Вашей ХП я вижу один входной параметр и ни одного выходного.
Отсюда я могу сделать вывод, что набор выходных полей будет либо динамическим либо пустым.
Так же, как по наличию синтаксиса args... в методе я могу догадаться о наличии неопределённого числа аргументов.
Но если окажется, что ХП вначале говорит, что вернёт три поля определённых типов, а в итоге возвращает два или двадцать полей неважно уже каких типов, то это будет вводить в заблуждение.
Я ведь специально создал такую строку с символами сразу из нескольких языков (французский + русский + румынский), чтобы не было сомнений в использовании Unicode.
PS: для iODBC Unicode вместо libcacheodbc.so нужно использовать libcacheodbciw.so: Key File Names
А вот unixODBC есть похоже только для 8-бит: ODBC Support
В других СУБД есть понятие отложенной перестройки индекса, т.е. вы данные модифицируете, но индекс при этом не пересчитывается.
Обычно используется при BULK insert.
Но чаще — как правило по умолчанию — индекс перестраивается немедленно при изменении данных.
И на это серверу просто необходимо потратить дополнительное время.
Какая стратегия постройки индекса была использована вами?
IMHO:
Выборка по первичному ключу должна происходить мгновенно, а не за 1,5 с. и даже не за 0,1 с.
Все приведённые цифры теста для меня слишком велики даже с поправкой на железо и VM, а потому сомнительны.
Хочу сравнить со своей СУБД.
15-20 минут, по-моему, слишком много.
День, когда я умер — The Day I Died (современные исследования околосмертных состояний)
Боюсь после такого откровения, ребёнок не захочет слушать сказки в моём исполнении.
Если представить, что на земле был бы только один человек, смог бы он себя познать до нашего уровня познания, имея в наличии только себя для исследования?
А главное — захотел бы?
Историю про барона Мюнхаузена — как он сам себя из болота вытаскивал — помните?
В идеале, конечно, было бы неплохо и детали не оставлять: а вдруг не те окажутся?
Сложность СУ 35 и человека несопоставимы.
Ожидать от ИИ любви, жалости, жертвенности, любопытства и т.п. — всего того, что присуще живым существам — не приходится.
Вы бы не могли уточнить каким именно на Ваш взгляд органом чувств (глаз, ухо, ...) мы это чувствуем?
А то здесь уверяют, что это не более чем просто «определённые механизмы мозга».
Только, чур, эмулятором не пользоваться, иначе система раздвоится на внутреннюю и внешнюю.
Конкретно для Вашей ХП я вижу один входной параметр и ни одного выходного.
Отсюда я могу сделать вывод, что набор выходных полей будет либо динамическим либо пустым.
Так же, как по наличию синтаксиса args... в методе я могу догадаться о наличии неопределённого числа аргументов.
Но если окажется, что ХП вначале говорит, что вернёт три поля определённых типов, а в итоге возвращает два или двадцать полей неважно уже каких типов, то это будет вводить в заблуждение.
Я ведь специально создал такую строку с символами сразу из нескольких языков (французский + русский + румынский), чтобы не было сомнений в использовании Unicode.
По ссылке выше я приводил пример на VBScript.
Если параметру присвоить 0 или вовсе убрать, то программа перестаёт правильно работать.
Включил ODBC-лог.
Вот, что у меня в него попадает с включённым параметром и без такового:
Locale Setting в данном случае означает текущую локаль ОС для дат, времени и т.д.
Поменял в «Панели управления» -> «Язык и региональные настройки» с румынского на немецкий и вот, что получаю в файл теперь:
PS: для iODBC Unicode вместо libcacheodbc.so нужно использовать libcacheodbciw.so:
Key File Names
А вот unixODBC есть похоже только для 8-бит:
ODBC Support