Про дизайн команды SQL WHERE

Встретил на bash-е:

“DileSoft: У команды UPDATE есть одна серьезная дизайнерская ошибка. Если скомандовать UPDATE table SET field=value, изменятся все строки в таблице table. Чтобы изменились не все, следует добавить WHERE. Это провоцирует серьезные проблемы, когда, забыв о WHERE, можно порушить огромное количество данных.

urandom: У дверей есть серьезная дизайнерская ошибка. Если прищемить яйца дверью, то яйца отвалятся.”

Мне очевидно, что комада WHERE спроектирована плохо, потому что синтаксис команды не защищает пользователя от ошибки (дает zero fool proof). Понятно, что “исторически сложилось”, “уже не поменять” и т.п. Я сейчас о другом.

Представьте, что было бы, если бы в интернет магазине вы забыли бы положить товар к корзину и оформили бы заказ, а вам в результате прислали бы все товары из магазина (и соответствующий счет).

С одной стороны, мы можем написать в help-е сайта, о том, что отсутствие товаров в корзине подразумевает выбор всех товаров, но с точки зрения нормального человека это нонсенс. И сколько было человеко-часов потрачено на исправления ошибок с пустым where – могу себе представить.

Думаю, что гораздо разумнее было бы задизайнить WHERE clause следующим образом:

1) Пустое WHERE возвращает пустор набор элементов;
2) WHERE с фильром ограничивает возвращаемые данные этим фильтром;
3) Специальное сочетание “WHERE ALL” возвращает весь набор элементов без фильтра.

В этом случае семантика клаузы WHERE была бы максимально приближена к естесственным языкам (что кстати и было одной из целей дизайнеров SQL).

А теперь про “яйца отвалятся”

Оппонент DileSoft-а показывает нам пример обычного, обывательского подхода: “Некто говорит нам что вещь, привычная и принятая в нашем обществе – неправильна –> Стебать этого самого некто”. Классическая травля несогласных в мини-масштабе.

Налицо позиция “то, что принято, оптимум есть”. А это ведь не так (почти всегда). И изменяют мир к лучшему как раз такие, как DileSoft, которые способны заметить и понять, что это не так.

Типа послесловия
Буквально неделю назад мы словили очень похожий баг в нашем продукте – API было спроектировано так, что некая бизнес операция применялась для всех клиентов в случае, когда не был указан фильтр.

В результате, из-за редкой ошибки в коде формирования фильтра (закончилось место на диске) он не был сформирован и вся наша команда получила незабываемые выходные, проведенные под знаком “руками все исправить быстро срочно”.

А вы говорите, WHERE…