Django создание данных и фиксация - PullRequest
0 голосов
/ 15 сентября 2009

Я не уверен, что на 100% понимаю, что делает база данных. Если у меня есть какое-то неправильное представление, пожалуйста, укажите на это.

Допустим, у меня есть функция, которая хочет создать 100 новых записей в базе данных с 100 000 записей.

Кажется, намного быстрее, когда эти 100 записей создаются, и фиксация выполняется после создания последней записи.

Теперь, если эти 100 записей созданы разными пользователями, существует ли простой способ фиксации только после создания 100 записей?

Edit: Должен ли я написать какой-нибудь буфер?

Ответы [ 3 ]

2 голосов
/ 16 сентября 2009

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

Во-первых, если бы была одна плохая запись, остальные потерпели бы неудачу. Это сделало бы 99 капризных пользователей из 100 (на самом деле 100, но у кого-то на самом деле не было бы причины быть капризным, потому что он сделал неправильный ввод данных для начала). Во-вторых, пользователи не увидят записи сразу после ввода. Также верно, что они не смогут что-то делать с этими записями до тех пор, пока они не будут введены, например, ввести данные в связанные таблицы. Такая задержка привела бы пользователей в замешательство. Если пользователи вводят данные от клиентов через телефонный звонок, они будут особенно капризны в ожидании (я работал в колл-центре с ужасно медленным коммерческим продуктом и, поверьте мне, я знаю, как расстроились пользователи, привыкшие получать!) В-третьих, пользователи будут переходить к чему-то другому и не осознают, что их данные были отклонены за недостоверную информацию, что вовсе не является хорошей вещью. Как долго вы будете ждать, чтобы получить установленное количество записей? 5 секунд, десять минут? Что произойдет, если по какой-либо причине соединение с сетью будет потеряно в течение этого времени, пользователи не потеряют введенные данные.

2 голосов
/ 15 сентября 2009

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

В предложенном вами решении проблема с любой вставкой в ​​пакете приведет к сбою всех других (возможно, полностью допустимых) вставок от совершенно разных пользователей. Кроме того, пользователи не смогут увидеть данные, которые они только что пытались вставить, потому что система ждала, чтобы выполнить вставку, пока пакет не будет заполнен.

P.S. Вот краткое введение в обработку транзакций .

1 голос
/ 16 сентября 2009

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

Чтобы пойти немного глубже, ваше приложение имеет:

  • объем памяти: переменные, которые вы определяете, например, в функциях просмотра. Все они разрушаются, когда поток покидает функцию.
  • globals: переменные, которые определены в самой внешней части вашего кода. Очень важно не использовать их для какого-либо состояния, кроме, возможно, констант конфигурации. Важно то, что вы должны полагаться на любое динамическое поведение. В противном случае вам придется бороться с параллельными и разветвленными процессами (в зависимости от шлюза сервера), которые не знают друг о друге. Только не делай этого.
  • схема кэширования, если вы решите ее реализовать. Это совершенно необязательно в django, и есть много способов сделать это. Однако обычно используется какая-то схема, чтобы гарантировать, что даже в случае сбоя кэша база данных точно отражает текущее состояние данных.
  • ваша локальная файловая система. С точки зрения дизайна большинство способов воспользоваться этим будет либо напоминать систему кэширования (см. Выше), либо будет неуклюжим и хрупким. С точки зрения производительности, он может быть примерно таким же медленным, как база данных.
  • ваша база данных.

Итак, вы видите, что у вас мало места для размещения ваших данных, кроме базы данных.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...