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

Question

Я занят разработкой 2 веб-систем с базами данных MySql, и количество таблиц / представлений / хранимых процедур действительно становится большим, и справляться со сложностью становится все сложнее.

Теперь в языках программирования у нас есть пространство имен, например Пакеты Java, пространства имен C ++ для разделения программного обеспечения, группировки его вместе, чтобы сделать вещи более понятными. С другой стороны, базы данных имеют более плоскую структуру (по крайней мере, MySql), например. таблицы и хранимые процедуры находятся на одном уровне. Поэтому нужно быть более креативным, создавать соглашения об именах, возможно, использовать более одной базы данных или использовать инструменты для визуализации вещей.

Какие методы вы используете, чтобы облегчить боль? Быть эффективным при разработке ваших баз данных? Чтобы не заблудиться в море таблиц, полей и хранимых процов?

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

b.t.w Сколько таблиц база данных должна была бы считать большой с точки зрения дизайна?

Answer 1

Единственное найденное мной решение, которое в целом применимо, - это разработать серию префиксов и применить их к таблицам (например, все таблицы, относящиеся главным образом к человеческим ресурсам, начинаются с hr_). Обычно я передаю префиксы другим «объектам» в приложении (формы, отчеты, представления, хранимые процедуры).

Это решение далеко от совершенства и является чем-то вроде взлома, но оно вносит хоть какой-то порядок в систему.

Answer 2

Oracle E-Business Suite имеет более 25 000 таблиц и около 33 000 просмотров. Я бы сказал, что это была большая схема.

Answer 3

Решение, которое хорошо работало для меня в одном проекте, состояло в том, что мы разделили базу данных на куски, затем мы нарисовали большой ERD (мы использовали Corel, хотя на самом деле есть много более интересных инструментов), мы пометили цвета ячейками для каждого стола, чтобы показать, какой кусок у каждого был, затем мы распечатали его на широкоформатном принтере, чтобы он был размером 5 футов и 10 футов в ширину, и мы повесили его на стене кабинета моего помощника. Не высокотехнологичное решение, но оно было невероятно практичным.

Мы также тщательно следили за последовательным наименованием, чтобы повторить ответ HLGEM.

В ретроспективе соглашение о присвоении имен, в котором каждое имя таблицы начиналось бы с "имени чанка", вероятно, было бы хорошей идеей, но без него мы справились бы неплохо.

Что касается того, насколько большой большой? Я не знаю, очень субъективный вопрос. Я вообще думаю, что база данных большая, когда я не могу представить все это в своей голове за один раз. В практическом плане, я думаю, когда вы проходите несколько десятков таблиц. Количество записей в значительной степени не имеет значения: базу данных с двумя таблицами, каждая из которых содержит миллиард записей, было бы легко понять; базу данных с 1000 таблицами, каждая из которых содержит десять записей, было бы трудно понять.

Answer 4

В некоторых базах данных у вас есть схемы, которые вы можете использовать, но я думаю, что не в mySQL. Соглашения об именах для хранения связанных таблиц - ваш лучший выбор. Одна вещь, которую я особенно стараюсь сделать, - это быть очень последовательным в именовании полей в разных таблицах абсолютно одинаково. Если моя таблица пользователей вызывает user_id, то я не хочу видеть его как person_id, userid, User и т. Д. В разных связанных таблицах. Также при использовании одного и того же типа поля из таблицы в таблицу используйте тот же тип данных (и размер, если это строковые данные). Тогда вам не придется постоянно преобразовывать данные для объединения.

Что касается того, сколько таблиц необходимо для большой базы данных, это больше зависит от количества записей в таблицах, а не от количества таблиц. Многие небольшие базы данных имеют сотни таблиц. Я бы почти никогда не беспокоился о количестве таблиц, если бы не увидел, как кто-то создает таблицы вроде Financials2009, Financials2010 и т. Д.

Answer 5

Ну ... в MySQL нет реального решения. С некоторыми базами данных (например, PostgreSQL) у вас есть пространства имен, и вы можете сделать это.

Конечно, вы можете обойти это, используя несколько баз данных для эмуляции пространств имен, но это может создать много проблем.

Лично я бы просто назвал все так, чтобы ваш инструмент управления мог его различить (например, phpMyAdmin автоматически использует подчеркивания для группировки баз данных).

Answer 6

Определенно, обязательно используйте соглашения об именах. Проектирование базы данных MySQL - одно из последних мест, где я использую венгерскую нотацию, но все мои таблицы начинаются с "tbl", все мои представления - с "v" и т. Д.

Кроме того, я строю несколько диаграмм базы данных в MySQL Workbench, обычно, по крайней мере, по одной диаграмме на совокупность доменов, которые помогают мне визуализировать «модули» в архитектуре.

Это одна из областей, где такой продукт, как Sql Server, имеет большие преимущества, поскольку объекты базы данных могут принадлежать нескольким схемам внутри базы данных, так же как пространства имен в программировании.

Answer 7

С другой стороны, базы данных имеют более плоскую структуру (по крайней мере, MySql)

... но у вас может быть несколько баз данных, работающих на одном экземпляре mysql, например

SELECT *
FROM common.address adr
purchasing.orders pod
WHERE pod.cust_id=adr.cust_id

(NB старайтесь избегать mysql 'USE dbname'). Хорошая идея стандартизировать ваши псевдонимы в запросах.

Сколько таблиц база данных должна была бы считать большой с точки зрения дизайна?

Я не думаю, что есть стандартная метрика. Я бы, наверное, запутался в 50. Одна из баз данных Oracle, за которой я следил, имеет 1567 (да, она нормализована (вроде))