Как оценить, является ли таблица хорошей или плохой в системе баз данных?

Неисчерпывающий список. По всем этим вопросам да, это хороший ответ, и нет ничего плохого.

1. Обеспечивает ли таблица четкую бизнес-функцию? Насколько хорошо он подходит для применения?
2. Является ли таблица хорошо названной? Хорошо ли названы столбцы таблицы? Может ли бизнес-пользователь понять, что они означают?
3. Имеет ли таблица первичный ключ?
4. Имеет ли таблица уникальные ограничения для всех бизнес-(кандидатов) ключей?
5. Определены ли все внешние ключи?
6. У всех столбцов с ограниченными значениями есть внешний ключ для таблицы ссылочных данных или контрольного ограничения (или enum для MySQL)?
7. У всех столбцов есть правильный (самый сильный) тип данных?
8. Правильно ли таблица правильно нормирована? (В среде OLTP, которая означает по крайней мере нормальную форму Boyce-Codd, на складах данных все по-другому).
9. Не содержит ли таблица каких-либо столбцов, содержащих "интеллектуальные ключи", строки CSV, JSON, XML, разные элементы данных, смысл которых зависит от метаданных, хранящихся в другом столбце (или другой таблице), или любой другой экзотической структуры, которая казалась хорошей идея в то время, но из-за чего после многих лет наступит наследие ужасного коллаборации и искажения данных?
10. Все столбцы скалярны, используя распознанные встроенные типы данных Oracle (т.е. Нет вложенных таблиц или пользовательских типов)?
11. Включена ли диаграмма модели физических данных в таблицу?
12. Является ли таблица выводимой из объектов диаграммой логической модели данных?
13. У вас есть сценарии DDL для таблицы и ее зависимых объектов? Являются ли эти сценарии в контроле источника?
14. Соответствует ли таблица тем стандартам и стандартам кодирования, которые у вас есть (если они есть)?
15. Является ли таблица физически реализована должным образом (например, все необходимые индексы, при необходимости организованы индексирование, разбиение на разделы, если необходимо)?
16. Является ли таблица защищаемой? Насколько удобно вы объясняете это другому опытному моделью данных, разработчику базы данных или бизнес-пользователю?

Как вы можете сказать, это упрямый список (вот почему некоторые люди голосовали, чтобы закрыть ваш вопрос). Некоторые моменты довольно неточны. Это, вероятно, далеко от модели, на которую вы надеялись.

Люди захотят спорить с некоторыми из этих мер. Например, речь идет о неатомных структурах данных, таких как JSON. Конечно, бывают случаи, когда такие структуры подходят; Я когда-то работал над системой, которая была бы намного проще, если бы мы хранили данные в столбцах XMLtype, а не измельчали их в реляционные таблицы. Но это изолированные случаи. Прочитайте некоторые вопросы на этом сайте о смарт-ключах, токенизируя строки CSV или записывая запросы против анти-модели Entity-Attribute-Value, чтобы понять, как много печали вызывают эти вещи. Первая нормальная форма должна быть заданной, а разработчики, которые ее нарушают, не заслуживают наличия баз данных.

Другими пунктами являются звонки. Если ваша организация не поддерживает обновленную физическую модель данных, то скорее всего, если не все ваши таблицы плохие (не обязательно, скорее всего). Поразительно, сколько мест, похоже, не поддерживает их сценарии DDL под контролем источника. Как они управляют своими развертываниями для тестирования и производства? Я думаю, что молитва сильно отличается.