Как создать таблицу для каждого пользователя для хранения данных табеля учета рабочего времени в Django
Я работаю над приложением для ведения табеля учета рабочего времени для клиента. Модель User в django используется для хранения данных пользователя. Но для хранения информации о пользователе, связанной с компанией (например, роль/должность, клиент, название проекта, отработанные часы, оценка отзывов), я использую таблицу табеля учета рабочего времени. Я хочу хранить отработанные часы за каждый день в отдельной таблице с внешней ключевой связью (с таблицей данных табеля) и создать отдельную таблицу для каждого пользователя, чтобы хранить данные о его отработанных часах отдельно.
Возможно ли такое в Django? Или хранить все данные об отработанных часах в одной таблице вроде бы просто, но со временем они будут накапливаться и поиск будет медленным? Так как каждый год будет накапливаться 150K записей (600 сотрудников, 250 рабочих дней в году, используется sqlite db).
Возможно ли это в Django?
Возможно, да, но часто это не очень хорошая идея. Обычно поиск не замедляется из-за количества записей.
Большинство баз данных работают с индексами[SQLite-doc]: это структуры данных, которые позволяют простой доступ к записям, имеющим, например, FOREIGN KEY для конкретной записи.
Несколько баз данных автоматически устанавливают индекс для столбца, который имеет ограничение FOREIGN KEY именно потому, что это почти тривиальный вариант использования для извлечения записей, относящихся к определенной связанной записи таблицы. SQLite этого не происходит, но это не такая уж большая проблема, потому что Django автоматически добавляет его для вас.
Такой индекс позволяет очень быстро найти местоположение связанных записей, и затем база данных может извлекать фактические записи без необходимость просматривать отдельные записи.
Это означает, что поиск масштабируется не в зависимости от общего размера таблицы, а в зависимости от размера извлекаемых записей.
Поскольку он будет накапливать 150 тысяч записей каждый год
Даже если это так, и даже если база данных не будет выполнять поиск наиболее оптимальным способом, это все равно не так уж и много. Базы данных часто могут работать с миллионами записей.
То, что вы описываете, это сегментирование [wiki] и сегментирование могут иногда это помогает, но часто бывает довольно сложно и болезненно сделать все правильно, особенно если в конечном итоге пользователю понадобится доступ к другому фрагменту. Если производительность не ужасна, а все остальные попытки не увенчались успехом, я думаю, что не стоит использовать сегментирование, поскольку у вас больше таблиц. Это означает, что запрос становится более сложным, сложнее создавать статистические данные: если предполагается, что менеджер должен легко определить для всех сотрудников, сколько они проработали в прошлом месяце, это уже не простое объединение, а результат сложного запроса, в котором вы объединяете данные в таблице каждого из связанных пользователей.