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

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

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

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

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

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

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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

Мы также были дотошны относительно последовательного именования, чтобы ответить на ответ HLGEM.

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

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

Ответ 7

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

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

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

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

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

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