SQL скорость запросов и уточнение

Question

Так что я просто создать базу данных, которая хранит только одну таблицу со следующими полями:

key_value: содержит 6-значный код для ключа

погашенной: логическое значение для если ключ погашается

redeemed_by: кто искупил его

redeemed_date: когда он был погашен

software_name: имя программного обеспечения т он относится к

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

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

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

Спасибо за любой ответ, я все еще изучаю базы данных и SQL!

Answer 1

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

Как отмечено Marc B, аппаратное обеспечение является вашим единственным вероятным фактором эффективности.

Answer 2

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

Рассуждение: Основная цель таблицы заключается в выгодах выкупа, а не для использования в качестве архива. Со временем, поскольку все больше и больше выкупленных записей находятся в таблице, производительность для поиска неиспользуемых записей начинает ухудшаться и ухудшаться из-за всего «мертвого дерева» в таблице. (Как вы думаете, eBay размещает все активные и завершенные аукционы в одном столе?)

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

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