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

Question

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

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

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

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

Редактировать: Для контекста:

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

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

Answer 8

Если это небольшие конфигурационные данные, я использую простой и распространенный формат. Ини, JSON и YAML обычно в порядке. Поклонникам Java и .NET также нравится XML. Короче говоря, используйте то, что вы можете легко прочитать в объекте в памяти, и забудьте об этом.