Как использовать соглашение о присвоении имен для больших баз данных?
Я занят, разрабатывая 2 веб-системы базами данных MySql, и сумма представляет стандартные программы в виде таблицы/просматривает/хранит, действительно становится много, и это все более сложно для обработки сложности.
Теперь на языках программирования у нас есть пространство имен, например, пакеты Java, пространства имен C++ для разделения программного обеспечения, собирая в группу его для создания вещей более понятными. Базы данных, с другой стороны, имеют больше плоской структуры (MySql, по крайней мере), например, таблицы, и хранимые процедуры находятся на том же уровне. Таким образом, нужно быть более творческим, создав соглашения о присвоении имен, возможно, использовать больше чем одну базу данных или с помощью инструментов для визуализации вещей.
Какие методы Вы используете для упрощения боли? Быть эффективным при разработке баз данных? Не потеряться в море таблиц и полях и сохранило procs?
Не стесняйтесь упоминать инструменты, которые Вы используете также, но пытаетесь ограничить его открытым исходным кодом и предпочтительно решениями Linux, если это в порядке.
b.t.w, Сколько таблиц база данных нужно было бы считать большими с точки зрения дизайна?
7 ответов
Единственное решение, которое я нашел, которое обычно применимо, - это разработать серию префиксов и применить их к таблицам (например, все таблицы, относящиеся в первую очередь к человеческим ресурсам, будут начинаться с hr_). Обычно я передаю префиксы другим «объектам» приложения (формам, отчетам, представлениям, хранимым процедурам).
Это решение далек от совершенства и в некотором роде напоминает взлом, но оно вносит некоторый порядок в систему.
Определенно, определенно используйте соглашения об именах. Дизайн базы данных MySQL - одно из последних мест, где я использую венгерскую нотацию, но я начинаю все свои таблицы с «tbl», все мои представления с «v» и т. Д.
Кроме того, я создаю несколько диаграмм баз данных в MySQL Workbench, как правило, по крайней мере, одна диаграмма на агрегат домена, которая помогает мне визуализировать «модули» в архитектуре.
Это одна из областей, в которой такой продукт, как Sql Server, имеет большие преимущества, поскольку объекты базы данных могут принадлежать нескольким схемам внутри базы данных, во многом подобно пространствам имен в программировании.
В некоторых базах данных есть схемы, которые можно использовать, но я думаю, что не в mySQL. Соглашения об именах, позволяющие объединить связанные таблицы, - ваш лучший выбор. Одна вещь, которую я особенно стараюсь сделать, - это быть очень последовательным в именовании полей в разных таблицах в точности одинаково. Если моя таблица пользователей требует user_id, я не хочу видеть его как person_id, userid, User и т. Д. В разных связанных таблицах. Также при использовании одного и того же типа поля от таблицы к таблице используйте один и тот же тип данных (и размер, если это строковые данные). Тогда вам не придется постоянно преобразовывать данные для выполнения соединений.
Что касается того, сколько таблиц вам нужно для большой базы данных, это больше зависит от количества записей в таблицах, а не от количества таблиц. Многие небольшие базы данных содержат сотни таблиц. Я почти никогда не стал бы беспокоиться о количестве таблиц, если бы не увидел, что кто-то создает такие таблицы, как Financials2009, Financials2010 и т. Д.
Oracle E-Business Suite имеет более 25 000 таблиц и около 33 000 представлений. Я бы сказал, что это была большая схема.
Что ж ... в MySQL нет реального решения. В некоторых базах данных (например, PostgreSQL) у вас есть пространства имен, и вы можете это сделать.
Вы, конечно, можете обойти это, используя несколько баз данных для имитации пространств имен, но это может создать множество проблем.
Лично я бы просто назвал все так, чтобы ваш инструмент управления мог их различать (например, phpMyAdmin автоматически использует подчеркивания для группировки баз данных).
Базы данных, с другой стороны, имеют более плоскую структуру (по крайней мере, MySql)
... но вы можете иметь несколько баз данных, работающих на одном экземпляре mysql, например
SELECT *
FROM common.address adr
purchasing.orders pod
WHERE pod.cust_id=adr.cust_id
(NB старайтесь избегать mysql 'USE dbname'). Хорошая идея - стандартизировать имена псевдонимов в запросах.
Сколько таблиц должна иметь база данных, чтобы считаться большой с точки зрения дизайна?
Я не думаю, что существует стандартная метрика. Я бы, наверное, начал путаться около 50. Одна из БД Oracle, за которой я присматриваю, имеет 1567 (да, она нормализована (вроде как))
Решение, которое хорошо сработало для меня в одном проекте, заключалось в том, что мы разделили базу данных на части, а затем нарисовали большой ERD (на самом деле мы использовали Corel, Хотя есть много более изящных инструментов), мы закодировали поля для каждой таблицы, чтобы показать, в каком куске каждый находится, затем распечатали его на широкоформатном принтере, чтобы он был примерно 5 футов в высоту и 10 футов в ширину, и мы повесили его на стене кабинета моего ассистента. Не высокотехнологичное решение, но невероятно практичное.
Мы также тщательно продумали согласованное именование, чтобы повторить ответ HLGEM.
Оглядываясь назад, можно сказать, что соглашение об именах, в котором к каждому имени таблицы добавлялось бы «имя блока», вероятно, было бы хорошей идеей, но без него мы неплохо справились.
Как большой большой? Не знаю, очень субъективный вопрос. Я обычно думаю, что база данных большая, когда я не могу вообразить все в своей голове за один раз. С практической точки зрения, я полагаю, когда вы проходите мимо нескольких десятков столов. Количество записей практически не имеет значения: базу данных с двумя таблицами, каждая из которых содержит миллиард записей, будет легко понять; базу данных с 1000 таблицами, каждая из которых содержит десять записей, будет трудно понять.