Есть ли какое-то жесткое и быстрое правило о том, насколько большой размер для таблицы SQL?
Мы сохраняем данные отслеживания SCORM в формате пары имя/значение, и может быть где угодно от 4-12 строк на пользователя за курс, по дороге это будет плохо, поскольку есть сотни курсов и тысяч пользователей?
У меня лично были таблицы в производстве с 50 миллионами строк, и это мало по сравнению с тем, что я слышал. Возможно, вам придется оптимизировать свою структуру с помощью partioning, но пока вы не протестируете свою систему в своей среде, вам не следует тратить время на это. То, что вы описали, это preety small IMHO
Я должен добавить, что я использовал SQL Server 2000 и 2005, каждая СУБД имеет свои собственные ограничения на размер.
Магическое число - миллиарды. Пока вы не доберетесь до миллиардов строк данных, вы вообще не говорите о очень больших данных.
Сделайте математику.
4-12 строк на пользователя за курс,... сотни курсов и тысячи пользователей?
от 400 000 до 1200 000 строк. Пусть предполагается 1000 байт в строке.
Это 400 Мб до 1,2 ГБ данных. Вы можете купить диски 100Gb за 299 долларов в магазине Apple. Вы можете легко потратить более $299 оплачиваемого времени на потение по деталям, которые не имеют большого значения.
Пока вы не доберетесь до 1 Тб данных (1000 Гб), вы вообще не говорите о многом.
100 (курсы) * 1000 (пользователей) * 10 (записи) - всего миллион. То, что низкий конец, но достойная база данных, должна справиться с этим хорошо.
Что звучит, если это пары Name/Value. Это ограничит вашу способность правильно индексировать вещи, что будет иметь решающее значение для хорошей производительности.
Нет жесткого и быстрого правила, но есть быстрый и быстрый способ получить число.
Напишите программу для заполнения вашей таблицы фиктивными данными, приблизительно приближающими ожидаемую форму фактических данных (например, аналогичную регулярность, символы, шаблоны и т.д.). Проведите тесты производительности с использованием реальных запросов с фиктивными данными, постепенно увеличивая количество строк в таблице, возможно, с шагом в 1000 или 10000 строк.
На пороге того, когда производительность запроса (например, запросы, завершенные в секунду) становится неприемлемой, у вас будет "слишком большое" количество строк.
Я когда-то работал над системой веб-форм с более чем 300 миллионами строк в таблице имен/значений. Многие из форм имели более 300 строк для представления формы. Производительность была не так уж плоха на самом деле, но это была полная PITA для запроса! Моя способность писать sql определенно улучшилась в течение жизни этого концерта.
Но ИМХО, если у вас есть какие-либо слова, избавитесь от него в пользу стандартной нормализованной таблицы.
Не совсем. Все зависит от потребностей вашего бизнеса, и вам придется покупать продукт, который поддерживает ваш оценочный ряд строк.
Нет, на самом деле нет жесткого правила о том, сколько строк вы можете иметь в таблице, это сильно зависит от количества данных в строках и насколько хорошо данные могут быть проиндексированы.
Быстрая оценка цифр, которые вы указали, дает нечто вроде десятков миллионов строк. Это, конечно, не слишком много, но достаточно, чтобы это могло быть проблемой, если вы не слишком осторожны.
Возможно, таблица может быть нормализована? Одинаковые имена встречаются так, что вы можете поместить имена в отдельную таблицу и использовать идентификатор в таблице?
Я не думаю, что здесь есть предел, а место на диске. НО ПОЖАЛУЙСТА добавьте хорошие индексы, в то время как их маленькие, потому что, когда таблица огромных индексов займет намного больше времени, чтобы добавить. Плюс, если у вас есть плохие индексы, запросы будут замедляться по мере того, как они появятся, и люди будут жаловаться, когда на самом деле нет ничего плохого, но дерьмового индекса нет.
Я работал над базами данных, где мы пытались создавать таблицы с двумя строками данных - это не сработало, мы добрались до 500M и переработали. Одной из самых больших ошибок в работе с такой большой таблицей было время, затраченное на удаление - я часто вижу подход, в котором архивные архивы архивируются, а затем удаляются из основной таблицы. Если таблица достаточно большая, чтобы удаление выполнялось в течение многих часов при восстановлении индексов.
Не уверен, где обрезание, но чувство кишки указывает на таблицу > 10M строк, вероятно, слишком велика. Наш подход заключался в разделении данных по дате, поэтому мы закончили таблицу за неделю данных и еще одну сводную таблицу в течение нескольких месяцев, а еще одно резюме в течение многих лет - очень распространенное в DataWarehousing. Кстати, это было на SQL 7.0, интересно узнать, лучше ли DB в этом типе вещей?
В вашем вопросе появляется больше вопросов, чем ответов.
Я создал несколько баз данных, хранящих данные SCORM, и мне никогда не приходилось использовать систему тегов/значений, как вы предлагаете.
Одна вещь, которую вы хотите запомнить, - это не число строк в таблице, а SIZE (в байтах) таблицы. Просто:
table size = size size (avg) * количество строк
Вопрос о том, "насколько большой стол слишком большой"?