Как вы обрабатываете небольшие наборы данных?
С действительно небольшими наборами данных я обычно работаю над тем, чтобы помещать их в текстовые файлы, но, по моему опыту, это может быть головной болью при разработке. Данные обычно поступают из базы данных, и когда это не так, процесс, участвующий в их настройке / хранении, обычно скрыт в коде. В базе данных вы обычно можете увидеть все доступные вам данные и способы их связи с другими данными.
Иногда для действительно небольших наборов данных я просто сохраняю их во внутренней структуре данных в коде (например, хэш Perl), но затем, когда требуется изменение, оно находится в руках разработчика.
Так как же обрабатывать небольшие наборы редко изменяемых данных? Вы установили критерии, когда использовать таблицу базы данных, текстовый файл или ..?
У меня есть соблазн просто использовать таблицу базы данных абсолютно для всего, но я не уверен, есть ли какие-либо последствия для этого.
Редактировать: Для контекста:
Меня попросили разместить на веб-сайте новую контактную форму для нескольких компаний, и в будущем время от времени будут добавляться новые. За исключением того, что у компаний нет контактных адресов электронной почты ... пользователи внутри этих компаний имеют (поскольку они публикуют вакансии через свои собственные учетные записи). Однако теперь нам нужна функциональность типа «спекулятивное приложение», а для формы требуется адрес электронной почты для отправки этих приложений. Но мы также не хотим указывать адрес электронной почты как свойство в форме, иначе спамеры могут просто использовать его как открытый шлюз электронной почты. Итак, ясно, что нам нужны отношения типа ID -> contact_email с компаниями.
Итак, я могу либо добавить столбец в таблицу с миллионами строк, которые будут использоваться буквально около 20 раз, либо создать новую таблицу, которая будет содержать не более 20 строк. Обычно в прошлом мы справлялись с этим, просто создавая неприятный текстовый файл и читая его оттуда. Но это создает кошмары обслуживания, и эти текстовые файлы часто просматриваются при изменении данных, от которых они зависят. Возможно, это ошибка процесса, но мне просто интересно услышать мнение по этому поводу.
Ответы 8
Поместите его в базу данных. Если он меняется нечасто, кешируйте его на среднем уровне.
Сразу приходит на ум пример, что уместно хранить в виде перечисления, а что уместно хранить в «поисковой» таблице базы данных.
Я стараюсь «провести черту» с правилом, что если это приведет к появлению столбца в базе данных, содержащего «магическое число», которое соответствует значению перечисления, тогда перечисление действительно должно существовать как таблица поиска. Если это не связано с данными, хранящимися в базе данных (например, данные конфигурации приложения, а не данные, созданные пользователем), то это полностью перечисление.
Конечно, использование набора данных независимо от размера зависит от пользователя разработанного вами программного инструмента?
Возможно, они просто знают Excel, поэтому вашему инструменту придется проанализировать созданный ими файл .csv.
Если он написан для разработчиков, то кого волнует, что вы используете. Однако я не фанат загромождения баз данных второстепенными или временными данными.
У нас есть стандартный формат файла конфигурации (ключ: значение) и класс для его обработки. Мы просто используем это во всех проектах. В основном мы просто устанавливаем постоянные свойства для наших приложений (разработка мобильных телефонов), так что это уместно. YMMV
В тех случаях, когда программа обращается к базе данных, я буду хранить все в ней: проще для резервного копирования и перемещения данных.
Для небольших программ без доступа к базе данных я храню свои данные в настройках .net, которые хранятся в файле xml - конечно, это особенность C#, поэтому она может не относиться к вам.
В любом случае, я стараюсь хранить все данные в одном месте. Обычно это база данных.
Если это небольшие данные, похожие на конфигурацию, я использую простой и распространенный формат. ini, json и yaml обычно подходят. Поклонники Java и .NET также любят XML. Короче говоря, используйте что-то, что вы можете легко прочитать в объект в памяти и забыть об этом.
Я бы добавил его в базу в основную таблицу:
- Резервное копирование и восстановление (вы ведь хотите восстановить этот текстовый файл?)
- Специальные запросы (поскольку вы можете сделать это с помощью инструмента SQL и присоединить его к другим данным базы данных)
- Если столбец базы данных пуст, требования к хранилищу для него должны быть минимальными (ничего, если это столбец NULL в конце таблицы в Oracle)
- Будет проще, если вы хотите иметь несколько серверов приложений, поскольку вам не нужно будет хранить несколько копий какого-либо дополнительного файла конфигурации.
- Помещение его в маленький детский столик только усложняет конструкцию, но не дает никаких реальных преимуществ.
Возможно, вы уже переходите к той же строке в базе данных как часть обработки, так что производительность вряд ли будет проблемой. Если нет, вы можете кэшировать его в памяти.
Вы считали sqlite? Она основана на файлах, что устраняет ваше ощущение, что «подойдет просто файл» (нулевая конфигурация), но это совершенно хорошая база данных и замечательно хорошо масштабируется. Он поддерживает ряд API, и для его администрирования есть многочисленные передние концы.
Я думаю, вам, возможно, придется добавить здесь некоторый контекст, чтобы получить хороший ответ.