Совет установки таблицы SQL

Если вы правильно индексируете, одна таблица будет работать быстрее. Вам обязательно понадобится индекс для вашего значения (который вы должны назвать как-нибудь иначе, поскольку «значение» - зарезервированное слово в sql).

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

Я предпочитаю один стол.

Я понимаю, что он не будет содержать данных только для одного импорта, но это то, что входит в предложение WHERE.

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

Что еще более важно, что вы будете делать, если по какой-то причине вы решите заниматься 45 раз в день, 90 раз в день или каждые 5 минут (12 * 24 = 288 раз в день). Создание 288 таблиц и изменение всех запросов, связанных с этими таблицами, будет огромным упражнением.

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

Как сказал Одед, реальных проблем с масштабированием / производительностью при 120 000 строках нет, поэтому я бы тоже выбрал уникальную таблицу (для простоты).

Если в будущем вам потребуется сильно масштабировать , просто помните эту статью о том, «почему базы данных SQL не масштабируются» . Помимо прочего, в статье объясняется, почему «разделение» (или «сегментирование») плохо для базы данных SQL:

сегментирование разделяет ваши данные по некоторому типу границ приложения. {{1} } Например, вы можете хранить пользователей , имена которых начинаются с AM, в одной базе данных , а NZ - в другой. Или используйте по модулю идентификатора пользователя на количество баз данных.

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

Таким образом, хотя сегментирование является формой горизонтального масштабирования, оно не соответствует пункту № 2: оно непрозрачно для бизнес-логики приложения.

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

Даже если изначально речь шла о разделении между большим количеством баз данных, та же концепция может быть применена к вашему случаю, когда вы пытаетесь добиться какого-то «внутреннего» разделения.

Заключение, ответ для реального масштабирования - NoSQL . Опять же, не с 120K строками :)

Вам нужен один стол. В противном случае вам пришлось бы написать 30 разных запросов или создать решение для динамических запросов (фу).

Насколько широки ряды? Более того, сколько строк умещается на странице 8k SQL? (На основании этого вы можете предположить количество операций ввода-вывода на вашем диске.) Сколько времени требуется вашему оборудованию, чтобы прочитать такой объем данных? Или все это может уместиться в памяти, чтобы вы не так часто ударяли по диску? Я хочу сказать, действительно ли у вас проблемы с производительностью?

Размещение составного кластерного индекса в таблице так, чтобы ваше значение «n» было первым столбцом, оптимизирует эти чтения (но только если у вас всегда есть значение «n» в предложении WHERE). В качестве альтернативы, если «n» всегда находится в диапазоне от фиксированных значений от 1 до 30 и вы используете SQL 2005 и выше, вы можете реализовать секционирование таблицы, которое даст вам такой же прирост производительности и, возможно, немного большей гибкости, когда дело доходит до загрузка или выгрузка данных.