Можно ли использовать словарь в базе данных для приложения с большим количеством записей?

Question

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

Прямо сейчас,У меня есть таблица для клиентов, таблица для продуктов и таблица для продукта-клиента (так как мы назначаем код для каждого продукта, который покупает клиент).Поскольку я хочу отслеживать остатки, есть также таблица сальдо.На данный момент мои модели выглядят так:

class Customer(models.Model):
    first_name = models.CharField(max_length=35)
    last_name = models.CharField(max_length=35)
    customer_ID= models.IntegerField(primary_key=True)
    phone = models.CharField(max_length=10, blank=True, null=True)

class Product(models.Model):
    product_ID = models.IntegerField(primary_key=True)
    product_code = models.CharField(max_length=25)
    invoice_date = models.DateField()
    employee = models.ForeignKey(Employee, null=True, blank=True)
    product_active = models.BooleanField()

class ProductCustomer(models.Model):
    prod = models.ForeignKey(Product, db_index=True)
    cust = models.ForeignKey(Customer, db_index=True)
    product_customer_ID = models.IntegerField(primary_key=True)
    [...]

class Balance(models.Model):
    product_customer = models.ForeignKey(ProductCustomer, db_index=True)
    balance = models.DecimalField(max_digits=10, decimal_places=2)
    batch = models.ForeignKey(Batch)
    [...]

Приложение вернет «историю» клиента.Если Pax был просрочен в какой-то момент, а затем он заплатил, а затем должен был вернуть деньги и т. Д.

Я думал, стоит ли мне вставить CharField на стол Pax, который будет содержатьсловарь с датой: статус (статус может быть вычислен и добавлен в словарь при загрузке информации), или если более эффективно выполнять запрос к таблице баланса, или если есть лучшее решение для реализации.

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

Answer 1

Если я понимаю ваш вопрос, вы, похоже, спрашиваете, будут ли условия объединения накладывать неоправданное бремя на ваш поисковый запрос.В некоторой степени это зависит от ваших rdbms.Я рекомендую вам использовать PostgreSQL поверх MySQL, потому что таблицы innodb в MySQL сильно оптимизированы для поиска по первичному ключу, и это означает, что для поиска записей о соединении необходимо пройти два btree.PostgreSQL, с другой стороны, допускает физическое сканирование таблиц, что означает, что поиск по внешнему ключу обычно выполняется немного быстрее.

В общем, да, подход со словарем подходит для приложения с большим количеством записей.Обычно вопросы возникают из-за того, как вы запрашиваете и сколько записей вы извлекаете в данном запросе.Это гораздо больший фактор, чем количество сохраненных записей, по крайней мере, для БД, подобного PostgreSQL.