WHERE
is_reg_town_verif = true
OR is_reg_street_verif = true
Насчет триггера, подавляющего изменения не нужных строк - это хорошая возможность (прежде всего если есть подозрения, что в приложении есть и много апдейтов, в которых нет некоторых ограничений), с другой стороны использование триггеров усложняет логику приложения (вижу апдейт всего, по факту нужно помнить, что есть триггер и проапдейтится только то, что нужно). В плане эффективности - если update без where - это в любом случае просмотр всей таблицы, так что добавление ограничения вида
WHERE
is_reg_town_verif = true
OR is_reg_street_verif = true
его не замедлят никаким образом, если по колонкам нет индекса. А если есть, то может и ускорить его.
Полагаю, что одни типы данных слегка быстрее, чем другие. Поскольку система 64х битная, то наверное ей легче работать с 64х битным типом данных, чем с 32х битным. Но это только предположение.
Полагаю, что с одной стороны проблема некритичная - разработчик может и сам расположить поля в оптимальном порядке, а с другой стороны доработка СУБД, чтобы она сама упорядочивала столбцы гораздо сложнее, чем кажется на первый взгляд.
Например, написали мы команду create table t1( a, b, c), где-то у нас в системе есть запросы вида select * from t1 (да, это плохой стиль написания запросов, но никто же не запрещает так писать). Всегда их результаты были аналогичны результату запроса select a, b, c from t1.
Тут вдруг выходит новый релиз системы, который сам оптимизирует столбцы в таблице. И запрос select * from t1 начинает возвращать столбцы в другом порядке - так, как select c, a, b from t1. Обратная совместимость потеряна, приложение сломано. Значит придется хранить в словаре данных 2 версии описания таблицы - одну точно как было в команде create table, другую - в оптимизированном виде. Поддерживать оба варианта в актуальном состоянии, где-то использовать 1-ю, где-то 2-ю. Не забыв, что бывают приложения, которые тоже читают словарь данных.
Ну и как, тут уже упоминали - при добавлении в сущесвующую таблицу нового столбца системе либо придется перестраивать всю таблицу, что может требовать больших ресурсов, либо таблица будет уже не совсем оптимальна. В последнем варианте, разработчику придется помнить, что при создании таблицы система сама ее оптимальной сделает, а при добавлении новых столбцов - нет.
После замены boolean на char(1) в моем примере таблица увеличилась на 8.5% (с 118 до 128Mb). Запрос значительно замедлился (среднее время выполнения 671 мс вместо 410).
Если же использовать "char" (чего делать не стоит, раз данный тип только для внутренних нужд СУБД), то размер таблицы не меняется (118 Mb), запрос несколько ускоряется (среднее время 370 мс).
Статья про технологию работы с Oracle, а не про гос-заказчиков. Про другие СУБД, с которыми мы работаем, будут еще статьи.Каждый из клиентов компании, расположенных по всему миру, вправе выбирать, какая СУБД ему подходит лучше.
Согласен, что
выглядит короче, красивее и читается легче, чем
Насчет триггера, подавляющего изменения не нужных строк - это хорошая возможность (прежде всего если есть подозрения, что в приложении есть и много апдейтов, в которых нет некоторых ограничений), с другой стороны использование триггеров усложняет логику приложения (вижу апдейт всего, по факту нужно помнить, что есть триггер и проапдейтится только то, что нужно). В плане эффективности - если update без where - это в любом случае просмотр всей таблицы, так что добавление ограничения вида
его не замедлят никаким образом, если по колонкам нет индекса. А если есть, то может и ускорить его.
Полагаю, что одни типы данных слегка быстрее, чем другие. Поскольку система 64х битная, то наверное ей легче работать с 64х битным типом данных, чем с 32х битным. Но это только предположение.
Полагаю, что с одной стороны проблема некритичная - разработчик может и сам расположить поля в оптимальном порядке, а с другой стороны доработка СУБД, чтобы она сама упорядочивала столбцы гораздо сложнее, чем кажется на первый взгляд.
Например, написали мы команду create table t1( a, b, c), где-то у нас в системе есть запросы вида select * from t1 (да, это плохой стиль написания запросов, но никто же не запрещает так писать). Всегда их результаты были аналогичны результату запроса select a, b, c from t1.
Тут вдруг выходит новый релиз системы, который сам оптимизирует столбцы в таблице. И запрос select * from t1 начинает возвращать столбцы в другом порядке - так, как select c, a, b from t1. Обратная совместимость потеряна, приложение сломано. Значит придется хранить в словаре данных 2 версии описания таблицы - одну точно как было в команде create table, другую - в оптимизированном виде. Поддерживать оба варианта в актуальном состоянии, где-то использовать 1-ю, где-то 2-ю. Не забыв, что бывают приложения, которые тоже читают словарь данных.
Ну и как, тут уже упоминали - при добавлении в сущесвующую таблицу нового столбца системе либо придется перестраивать всю таблицу, что может требовать больших ресурсов, либо таблица будет уже не совсем оптимальна. В последнем варианте, разработчику придется помнить, что при создании таблицы система сама ее оптимальной сделает, а при добавлении новых столбцов - нет.
После замены boolean на char(1) в моем примере таблица увеличилась на 8.5% (с 118 до 128Mb). Запрос значительно замедлился (среднее время выполнения 671 мс вместо 410).
Если же использовать "char" (чего делать не стоит, раз данный тип только для внутренних нужд СУБД), то размер таблицы не меняется (118 Mb), запрос несколько ускоряется (среднее время 370 мс).
Статья про технологию работы с Oracle, а не про гос-заказчиков. Про другие СУБД, с которыми мы работаем, будут еще статьи.Каждый из клиентов компании, расположенных по всему миру, вправе выбирать, какая СУБД ему подходит лучше.