Как правильно организовать такую БД?

Question

[lukoie]

По почте приходит каждый месяц ДБФ.
Оно по пхп забирается, парсится в sql. В итоге из БД на 20 колонок и от 10 до 100 строк(как когда) надо только 3-4 колонки для наших нужд приложения.
Если подключаем 100-1000-10000 клиентов с такой же задачей, получается что каждый месяц мы втягиваем 100-1000-10000 таких БД и для каждого клиента раскидываем только 3-4 колонки по его таблице. И так каждый месяц.

Вопрос: как правильней это организовать? Хранить все записи полностью, или забирать нужное, остальное удалять, и в архив на сервере ложить дбфки?

Comments

[sim3x]

Нет "правильного" решения
( Вернее, есть, но там нет дбф, пхп, пересылки по почте дбф )

Есть то которое оговорено со всеми и все понимают, как его делать

То что со стороны кода приходится отсеивать данные - не проблема и ее не надо "решать"

Если требуется что-то хранить для проверок, то храните дбф

В БД не должно быть дублирования

[lukoie]

sim3x: имеем данность -
1 по почте и
2 дбф.
это надо использовать
3 в софте на ларавеле
4 для многих пользователей
5 в их кабинетах только некоторые колонки будут обрабатываться и использоваться
Нужен наиболее правильный способ обходиться с этими данными и ДБФ файлами.

Со стороны кода мы отсеивам данные, берем только нужное. Но что делать со всеми данными?
Пока решение - втягивать всю ДБФ в SQL, И брать нужные данные.

Но что дальше делать с лишними данными, которые мы втянули скопом? Хранить, потому что относительно не много, или все таки например делать временную таблицу, куда вливать всю дбф, оттуда брать данные для постоянной таблицы, а временную удалять?

Для проверок хранить не нужно - оно если надо есть у клиента в почте. Мы только нужное спарсим для своих отчетов.

[sim3x]

lukoie: втягивать в темп таблицу, после загрузки в основную таблицу, темп таблицу - удалять

[sim3x]

lukoie: дбф стоит менять на прямое общение с апи
В дбф может быть много лишнего, в том числе и вредоносный код

Клиент имеет инет - пусть пушит данные в апи с проверкой

[lukoie]

sim3x: не вариант, дбф присылает гос.контора.
там и есть много лишнего, потому что дбф берется из их общей БД, вычленяется для отдельного предприятия. там и индекс улицы, и название улицы, и еще куча их внутренних индексов, т.к. БД общая для всей страны.

клиент не будет пушить данные. это собес. у них всё как всегда/пока допотопно. потому надо для программы выписки актов и отчетов подстроиться под их воркфлоу.

Answer 1

[stoitli]

Если нет проблем с местом - я бы хранил все.
Мало ли. Для разборок может пригодится.
А так - эти объемы для современных СУБД ерунда, семечки.

Answer 2

[Александр Шелеметьев]

Обычно для таких задач организую отдельную таблицу для импорта данных. Запихиваю туда всё, что пришло извне. Затем обрабатываю в отдельном потоке (нескольких потоках): записываю только нужные данные в основные таблицы. При этом ставлю флаг или сообщение об ошибке у обработанных записей таблицы импорта. Потом проще разобраться, что обработалось, а что нет и почему. И не придётся повторно загружать внешние файлы.
Когда процесс отлажен, ставлю периодическую задачу на подчистку (или архивацию, если нужна будет сверка) старых данных в таблице импорта. Можно запускать в пром.