Создать страничку для проверки целостности/корректности/консистентности БАЗЫ

[Denis_N]

Есть идея создать страничку для проверки, чтобы в базе все было консистентно. И просьба вас предлагать правила на которые было бы полезно базу периодически проверять базу через скрипт.

Некоторые уже правила проверки:

1. Проверить, что имена изделий в таблице products совпадают с именами в таблице order-items. Нужно правило по просьбе Саши по причине того, что он может по просьбе Олега изменить в одной таблице имя изделия, а в другой ошибиться или забыть.

P.S. Просьба после предложения правила написать обоснование для него.

[alx]

Replying to Denis_N:

Есть идея создать страничку для проверки, чтобы в базе все было консистентно. И просьба вас предлагать правила на которые было бы полезно базу периодически проверять базу через скрипт.

Идея хорошая и здравая, только непонятно, зачем скрипту страница (если я правильно понял, что имеется в виду веб-страница)... :)

1. Проверить, что имена изделий в таблице products совпадают с именами в таблице order-items. Нужно правило по просьбе Саши по причине того, что он может по просьбе Олега изменить в одной таблице имя изделия, а в другой ошибиться или забыть.

Непонятно, зачем Саше может потребоваться изменять имя изделия в БД руками. Если одно изделие было переделано в другое, то, насколько я понимаю, для этого в веб-интерфейсе есть страница "Трансформация", код которой должен все нужные изменения в БД сделать автоматически (разукомплектовать заказ, если он был скомплектован данной платой). Если же заказчик изменил состав своего заказа - для этого тоже в веб-интерфейсе есть интерфейс "Заказы", где старая позиция удаляется, и добавляется новая, в результате чего новая позиция оказывается нескомплектованной автоматически!

Еще одно соображение. Неконсистентность может возникнуть там, где есть избыточность. Поэтому, прежде чем добавлять какую-то проверку в скрипт, стоит подумать, а нельзя ли эту избыточность устранить. Ведь если устранить причину, то не надо будет бороться с ее последствиями! Например в той же таблице order-items я вижу столбцы type и name, дублирующие (насколько я понял) одноименные столбцы таблицы list_of_products. Если удалить столбец type из таблицы order-items (и вместо него использовать столбец type таблицы list_of_products, то есть чуть-чуть лучше нормализовать БД), то и не надо будет потом в таблице order-items проверять соответствие наименования изделия его типу...

Теперь по сути заданного вопроса. Насколько я понимаю, проверять надо все места, где есть избыточность (как в случае с именами, упомянутом в описании тикета), и где есть агрегированные поля (например поле mismatch в таблице products).

И еще одно предварительное замечание: ты просишь предлагать правила для проверки консистентности БД, но я нигде не видел документации на БД, где были бы четко описаны назначения полей - какое поле в каких случаях какое значение должно принимать. Есть такое описание? Без него о назначении большинства полей я могу только гадать и, соответственно, предлагаемые мной правила проверок - тоже не более чем гадание... :)

1. Значение поля name в таблице products должно иметься в таблице list_of_products. Нужно по причине того, что в таблице для этого поля отсутствует FOREIGN KEY, и в результате ошибки в коде или при ручной правке БД в записи может оказаться имя несуществующего в действительности изделия, что будет запутывать пользователей и, возможно, приводить к наведенным ошибкам.
2. Поле type в таблице products должно совпадать с полем type в таблице list_of_products с тем же полем name. Нужно по причине того, что здесь имеется избыточность, и в результате ошибки в коде или при ручной правке БД в записи может оказаться ошибочный тип изделия, что будет запутывать пользователей.
3. Значение поля owner в таблице products должно иметься в таблице users. Нужно по причине того, что в таблице для этого поля отсутствует FOREIGN KEY, и в результате ошибки в коде или при ручной правке БД в записи может оказаться ссылка на несущетвующего пользователя, что будет запутывать других пользователей и, возможно, приводить к наведенным ошибкам.
4. Поле location в таблице products должно соответствовать полю location последней записи для данного изделия в таблице history, в которой это поле не пустое (не NULL). Нужно по причине того, что в результате ошибки в коде или при ручной правке БД в записи может оказаться ошибочное местоположение, что приведет к потере ценного изделия.
5. Поле testing в таблице products должно соответствовать полю status последней записи типа testing для данного изделия в таблице history. Нужно по причине того, что в результате ошибки в коде или при ручной правке БД в записи может оказаться ошибочный статус тестирования, что приведет к отгрузке негодного изделия, что, в свою очередь, нанесет урон репутации компании.
6. Поле otk в таблице products должно соответствовать полю status последней записи типа otk для данного изделия в таблице history. Нужно по причине того, что в результате ошибки в коде или при ручной правке БД в записи может оказаться ошибочный результат контроля ОТК, что может привести к отгрузке изделия, не прошедшего контроль ОТК.
7. Поле mismatch в таблице products должно быть yes если есть хотя бы одно неустраненное несоответствие и no во всех остальных случаях. Нужно по причине того, что в результате ошибки в коде или при ручной правке БД в записи может оказаться ошибочный статус, что может привести к отгрузке негодного изделия, что, в свою очередь, нанесет урон репутации компании.
8. Поле type в таблице order-items должно совпадать с полем type в таблице list_of_products с тем же полем name. Нужно по причине того, что здесь имеется избыточность, и в результате ошибки в коде или при ручной правке БД в записи может оказаться ошибочный тип изделия, что будет запутывать пользователей.