Ответ 1
У вас должно быть ровно столько таблиц, сколько вам нужно; не более, не менее.
Одна из систем, над которыми я работаю в эти дни, имеет 143 таблицы - потому что это точно количество, необходимое для решения проблемы.
Я искал stackoverflow около часа и не мог найти никаких связанных тем, поэтому приношу свои извинения, если это дублированный вопрос.
Мой запрос таков. Есть ли точка, в которой слишком много таблиц в базе данных? Даже если структура хорошо организована, продумана и идеально подходит для дизайна? У меня есть база данных, которая быстро приближается к 40 таблицам - около 10 основных и более 30 вспомогательных таблиц (таблицы соединений, таблицы перечисления и т.д.).
Я просто плохой разработчик, или мне нужно попробовать что-то другое? Мне кажется, что так много для меня, я действительно боюсь, как это повлияет на производительность проекта. Я сделал много уплотнений, где это возможно, сгруппировал похожие вещи, где это возможно, и т.д.
База данных построена в SQL Server 2008.
У вас должно быть ровно столько таблиц, сколько вам нужно; не более, не менее.
Одна из систем, над которыми я работаю в эти дни, имеет 143 таблицы - потому что это точно количество, необходимое для решения проблемы.
LOL наш главный db имеет более 700 таблиц, я не работал с базой данных, поэтому у нее было всего 40 таблиц за много лет.
Пока у вас есть таблицы, которые вам нужны, и они нормализуются, вы в порядке.
Я видел больше проблем с производительностью, вызванных слишком большим количеством таблиц, чем слишком много.
Кажется, вы прилагаете все усилия, чтобы нормализовать свою базу данных. Это хорошо. Много раз проблемы возникают из-за нехватки таблиц.
Не зная ничего о вашей конкретной базе данных, я бы сказал, что нет, вы не используете слишком много таблиц. Проблемы реального мира и бизнес-потребности могут легко указать на схему, которая по крайней мере такая же, как ваша. Я думаю, что реальный вопрос: спросите ли вы, правильно ли ваш дизайн для вашей проблемы.
Существует такая вещь, как слишком много таблиц, но 40 ничего подобного. И когда люди начинают окутывать пределы продукта, тогда обычно это вопрос, когда им нужно переосмыслить их дизайн.
Для SQL-сервера ограничение максимальной емкости указывает, что БД может содержать ~ 2000000000 таблиц (если в нем нет ничего другого, нет ПК или ограничения любого рода и т.д.). Излишне говорить, что если вы нажмете этот предел, то вы делаете что-то не так (например, вы решили иметь 1 таблицу на одного клиента и как-то вы на самом деле набрали много клиентов)
Это действительно зависит от сложности приложения, которое вы пытаетесь реализовать. Такие вещи, как системы бухгалтерского учета, довольно интенсивно, легко достигают 40 + таблиц.
2147483648 таблицы или более могут быть проблематичными с некоторыми двигателями. 9223372036854775808 таблицы или более могут быть проблематичными для некоторых других.
(Но если ваш вопрос означал, существует ли определенное число n, так что дизайн базы данных s > n таблицами обязательно должен быть ошибочным, тогда нет.)
В моей собственной работе у меня около 60 таблиц, и это кажется не очень) Я думаю, что главное, как организовано хранилище данных (отношения между таблицами и т.д.), сколько запросов вам нужно для получения необходимой информации и как простые данные могут быть представлены как объекты бизнес-приложения в вашем приложении.
Вы можете поместить все данные из ваших фактических таблиц в одну таблицу. Во вторую таблицу могут быть только ваши "имена таблиц", и приложение все равно будет работать.
Но здесь дело не в этом. Таблицы - это своего рода организационная структура. Это какие-то ящики.
У меня слишком много ящиков?
Это зависит...