Как вы обрабатываете небольшие наборы данных?

Question

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

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

Итак, как вы обрабатываете небольшие наборы редко изменяемых данных? Установили ли вы критерии использования таблицы базы данных или текстового файла или ...?

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

Edit: Для связи:

меня попросили поставить новую контактную форму на веб-сайте для нескольких компаний, с более быть добавлены иногда в будущем. Кроме того, у компаний нет контактных адресов электронной почты. Пользователи внутри этих компаний делают (поскольку они размещают вакансии через свои собственные учетные записи). Однако, мы хотим использовать функциональность типа «спекулятивного приложения», а для формы необходимо, чтобы адрес электронной почты отправлял эти приложения. Но мы также не хотим размещать адрес электронной почты в качестве свойства в форме, иначе спамеры могут просто использовать его в качестве открытого почтового шлюза. Настолько ясно, что нам нужны отношения ID-> contact_email с компаниями.

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

Answer 1

Если это небольшие конфигурационные данные, я использую простой и общий формат. ini, json и yaml обычно нормально. Фанатам Java и .NET также нравится XML. Короче говоря, используйте что-то, что вы можете легко прочитать в памяти объекта и забыть об этом.

Answer 2

Поместите это в базу данных. Если он изменяется нечасто, кешируйте его в своем среднем уровне.

Answer 3

Примером, который сразу приходит в голову, является то, что уместно сохранить в качестве перечисления и что необходимо сохранить в таблице базы данных «lookup».

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

Answer 4

Возможно, это зависит от пользователя программного обеспечения, разработанного вами для использования набора данных независимо от размера?

Возможно, они знают Excel, поэтому ваш инструмент должен будет проанализировать созданный ими CSV-файл.

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

Answer 5

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

Answer 6

В тех случаях, когда программа обращается к базе данных, я буду хранить все там: проще для резервного копирования и перемещения данных.

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

В любом случае, я гарантирую хранить все данные в одном месте. Обычно база данных.

Answer 7

Я хотел бы добавить его в базу данных в главной таблице:

1. Резервное копирование и восстановление (вы хотите восстановить этот текстовый файл, верно?)
2. Adhoc обработку запросов (так как вы можете сделать это будет инструмент SQL и присоединить его к другим данным базы данных)
3. Если столбец базы данных пуст, требования к хранилищу должны быть минимальными (ничего, если это столбец NULL в конце таблицы в Oracle)
4. Это будет быть проще, если вы хотите иметь несколько серверов приложений, так как вам не понадобится t о хранить несколько копий некоторого дополнительного файла конфигурации вокруг
5. Собирают в столику ребенка только усложняет конструкцию, не давая никаких реальные преимущества

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

Answer 8

Считаете ли вы, что sqlite? Это основано на файлах, в котором говорится о том, что «просто файл может делать» (нулевая конфигурация), но он отлично подходит для базы данных и отлично масштабируется. Он поддерживает несколько API, и для его администрирования есть numerous front ends.