Interbase, Firebird, Yaffil
Что НЕ надо делать при работе с Interbase, Firebird, Yaffil
Оптимизация приложений для работы с СУБД InterBase
Оптимизации подзапросов в InterBase
Во-первых, подзапрос, как правило, можно написать в том месте, где требуется получить/вычислить какое-либо одно значение. В этом случае просто на месте значения пишут подзапрос в скобках. При этом фраза select этого подзапроса должна возвращать ровно одно поле, а логика остальных частей должна обеспечивать, чтобы возвращалось не более одной записи. Если не будет сформировано ни одной, то подзапрос возвращает null, если же несколько, то возникнет ошибка. Подзапросы подобного рода могут фигурировать, в частности, в вычисляемых выражениях или в операциях сравнения.
Системные таблицы InterBase
Системные таблицы InterBase содержат метаданные базы данных. Они создаются автоматически сервером InterBase, когда создается сама база данных. Информация, содержащаяся в этих таблицах, определяет типы полей таблиц, их названия, связи между таблицами и пр. Эти таблицы сопровождаются сервером, и их, конечно, лучше не менять. Я бы сказал, что лучше принять все меры к тому, что бы они были недоступны пользователю.
InterBase: тормозология и глюконавтика
Если суммировать мысли кратко, то по поводу тормозологии interbase: когда делаешь что-то серьёзное, ни одна СУБД не сделает всё за тебя. То есть наличие супер-пупер умного оптимизатора не спасает от проблем, а лишь отодвигает их. В конечном итоге это в чём-то даже хуже, потому что когда ты упрёшься в проблемы, то будет наделано уже столько, что не исправишь. И в этой ситуации начинает играть роль не интеллект оптимизатора, а возможности ручного управления отработкой запросов interbase. В конце концов, ни один оптимизатор не знает о семантике запроса столько, сколько знает разработчик interbase (иначе это не разработчик, а ...). Вот тут-то оказывается, что interbase при внешней простоте предоставляет очень широкие возможности для управления. Фактически, более крутую вещь я видел в PostgreSQL - там можно оптимизатору собственные правила подсовывать, то есть делиться опытом. А уж что касается таких попсовых вещей, как MS SQL, то они interbase в плане управляемости в подмётки не годятся.
Если суммировать мысли кратко, то по поводу тормозологии interbase: когда делаешь что-то серьёзное, ни одна СУБД не сделает всё за тебя. То есть наличие супер-пупер умного оптимизатора не спасает от проблем, а лишь отодвигает их. В конечном итоге это в чём-то даже хуже, потому что когда ты упрёшься в проблемы, то будет наделано уже столько, что не исправишь. И в этой ситуации начинает играть роль не интеллект оптимизатора, а возможности ручного управления отработкой запросов interbase. В конце концов, ни один оптимизатор не знает о семантике запроса столько, сколько знает разработчик interbase (иначе это не разработчик, а ...). Вот тут-то оказывается, что interbase при внешней простоте предоставляет очень широкие возможности для управления. Фактически, более крутую вещь я видел в PostgreSQL - там можно оптимизатору собственные правила подсовывать, то есть делиться опытом. А уж что касается таких попсовых вещей, как MS SQL, то они interbase в плане управляемости в подмётки не годятся.