Плохой дизайн базы данных - моя таблица слишком велика?

Какая СУБД? Какой сервер? Какая нагрузка? Какое приложение?

Кроме того: 11.000 записей - это вообще ничего. Даже в MS Access. :-)

Обновлено: Итак, я предполагаю, что вы используете довольно недавний MySQL с таблицами MyISAM. Теоретически вы можете заполнить таблицу миллионами записей. В зависимости от того, как вы с ними работаете (много соединений / или нет, много запросов / обновлений / удалений / или нет), вам не нужно делать ничего особенного. Поместите правильный индекс в таблицу, и все будет в порядке.

Что вы имеете в виду под «плохо спроектированной базой данных»?

Если он плохо спроектирован, перепроектируйте его, перетащите информацию из текущих таблиц и заполните новую.

Если вас беспокоит производительность, 11000 записей - это немного. База данных размером 15 мегабайт чрезвычайно мала по стандартам db.

Я не думаю, что вы предоставляете достаточно информации, чтобы кто-то мог дать ответ. Почему он плохо спроектирован? Это не нормализовано? У вас нет индексов? Что это за БД? На какой ОС он работает? Сколько времени нужно сейчас, чтобы запросить запись из рассматриваемой таблицы?

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

11к записей - это не так уж и много. 50К тоже не большие.

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

Однако, если дизайн достаточно плохой, вы можете подумать о стоимости редизайна.

Размер стола не имеет большого значения. Дизайн ключа, индексов и отношений имеет гораздо большее отношение к качеству дизайна, чем размер содержащихся в нем данных. Очевидно, здесь есть предостережения; но оптимизация размера таблицы - это почти последнее, что я делаю, когда работаю над проблемой производительности или дизайна.

Возможно, вы захотите подробнее объяснить, почему вы считаете, что это плохо спроектированная база данных, и что вы можете (легко) сделать, чтобы исправить проблемы. Наряду с этим вы должны подробно описать тип СУБД и ее использование (веб-приложение, настраиваемое приложение, отчетность и т. д.).

15МБ - это ничего. Так же 11к рядов. У меня есть базы данных с 2+ ГБ данных, а некоторые таблицы содержат более 1 миллиона строк, и я считаю, что это где-то между малым и средним размером.

Вы действительно не предоставили никаких доказательств в поддержку своего утверждения о том, что это плохо спроектированная база данных. Что делает его плохо спроектированным? в таблице 876 столбцов? Столбцы называются Col1, Col2, Col3 ...? Использует ли он float и datetime в качестве составного первичного ключа? Это плохо нормализовано? Единственное, о чем мы знаем, - это количество записей.

Если вы говорите о SQL Server 2005, загляните в профилировщик SQL Server и воспользуйтесь мастером настройки индекса.

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

То, из чего состоит запись, может иметь большее значение, чем количество записей в таблице.

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

С точки зрения базы данных 11К записей - это обычно ничто.

Что еще заставляет вас думать, что база данных плохо спроектирована, если не считать количества записей в одной таблице?

Вам нужно предоставить гораздо больше информации о структуре таблицы.

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

Я понимаю, что вы беспокоитесь, если увеличение количества записей примерно до 55 000 в «вашей плохо спроектированной базе данных» повлияет на производительность.

Если теперь ваша система работает так, как ожидалось, я думаю, у вас тоже будет все в порядке с 50 000 записей, если у вас уже нет небольших проблем с производительностью.

Поскольку большинство людей упомянули, что 50 тыс. Записей - это очень небольшое число по сравнению с размером таблицы базы данных, и даже с ненормализованной базой данных не должно быть проблем с производительностью.

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

Если вы собираетесь расширить свою систему, сейчас самое время переделать ее, если в этом возникнет необходимость. Когда у вас 11 000 записей, гораздо менее болезненно менять дизайн, чем когда у вас 10 миллионов. Однако ничто из того, что вы сказали, не указывает мне на то, что вам нужно изменить дизайн. Нет ничего плохого в наличии соединений (на самом деле, хорошо спроектированная база данных должна иметь их). Опубликуйте некоторые подробности о конструкции, и мы поможем вам решить, нужен ли редизайн.

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