InterBase: тормозология и глюконавтика
|
|
Страница 1 из 38
Если суммировать мысли кратко, то по поводу тормозологии interbase: когда делаешь что-то серьёзное, ни одна СУБД не сделает всё за тебя. То есть наличие супер-пупер умного оптимизатора не спасает от проблем, а лишь отодвигает их. В конечном итоге это в чём-то даже хуже, потому что когда ты упрёшься в проблемы, то будет наделано уже столько, что не исправишь. И в этой ситуации начинает играть роль не интеллект оптимизатора, а возможности ручного управления отработкой запросов interbase. В конце концов, ни один оптимизатор не знает о семантике запроса столько, сколько знает разработчик interbase (иначе это не разработчик, а ...). Вот тут-то оказывается, что interbase при внешней простоте предоставляет очень широкие возможности для управления. Фактически, более крутую вещь я видел в PostgreSQL - там можно оптимизатору собственные правила подсовывать, то есть делиться опытом. А уж что касается таких попсовых вещей, как MS SQL, то они interbase в плане управляемости в подмётки не годятся.
По поводу глюконавтики: да, глюки есть и их много. Но примерно столько же, сколько и у других. И не настолько много, чтобы сделать невозможной реализацию сложных систем. По крайней мере, если не кидаться сломя голову на каждую новую версию. Собственно, для того, чтобы можно было заранее избежать проблем я этот документ и пишу. Предполагается, что читатель знаком с основами БД вообще и InterBase в частности и хочет расширить свои познания. В прочем, не откажусь от обратного - если кто-то найдёт неточности, выскажет пожелания, или поделится своим опытом, всё это будет воспринято. В общем, это - не учебник. |