В этом случае было бы лучше хранить данные в базе данных, такой как SQLite, или в текстовом файле?
Я создаю небольшой проект C ++, который будет использовать статические данные (они не будут изменены на стороне пользователя, обновляются только тогда, когда требуется изменение). Сами данные будут состоять из пяти различных категорий Предметы с различными поля. Примером этих предметов будет:
item1 {a=3, b=2, d=4}
item2 {c=4, d=2, m=3}
...
Каждый элемент может содержать любое количество полей (a-z для этого примера) со связанным значением. Каждая категория будет иметь список элементов (например, пять разных файлов, содержащих строки текста, как указано выше).
Цель программы состоит в том, чтобы найти один элемент из каждой из этих категорий, где различные поля, которые они содержат, будут суммироваться для удовлетворения требуемого ввода (то есть сумма (d) == 10, сумма (x) == 20). Полученные пять пунктов будут соответствовать как минимум этим требованиям. Я стремлюсь к этому, находя декартово произведение пяти различных категорий (после сужения его путем нахождения только элементов, которые содержат хотя бы одно поле из входных данных), а затем циклически перебирая результаты, чтобы найти наборы из пяти элементов это правильно.
Теперь на мой вопрос: мне любопытно, будет ли лучше хранить данные в текстовом файле (и загружать их при каждом запуске) или использовать SQLite. Использование текстовых файлов, безусловно, было бы лучше реализовать, по крайней мере для меня. Но я уверен, что загружать все и сохранять его в надлежащих объектах данных при каждом запуске программы будет не так эффективно.
С SQLite я бы сразу получил все в свое распоряжение и смог бы выполнять большинство моих задач непосредственно с помощью запросов. Я немного сомневаюсь в том, как мне сузить таблицы, прежде чем найти декартово произведение, а затем продолжить циклически просматривать результаты для ответов. Я уверен, что смогу понять это со временем и исследованиями.
Итак, эксперты StackOverflow, что вы думаете об этом? Если бы не конкретные операции, которые я планирую провести над данными, я бы выбрал SQLite. Но с этим я немного не уверен, и хочу быть уверен, что сохраню простоту этого в долгосрочной перспективе.
Решение
Частично это продиктовано тем, сколько записей вы планируете хранить — при определенном размере преимущества СУБД начинают проявляться по сравнению с гигантским плоским файлом, заглушающим вашу оперативную память.
Правила, о которых вы говорите, действительно просты для запросов, и вы получите преимущества надежности, проверки целостности данных и другие преимущества, которые дает СУБД. Если бы это был я, я бы ходил на SQLite весь день.
Другие решения
Использование SQLite сделает базу данных масштабируемой, так как, основываясь на запросах, будет быстрее выполнять манипуляции, особенно если необходимо выполнить какую-либо новую операцию.
Управление файловой системой, основанное на разделителях, было бы намного проще реализовать, поскольку оно не требовало бы понимания языка запросов.
SQLite — это чужой код, в то время как FMS будет «ВАШИМ» кодом, поэтому любые обнаруженные ошибки или проблемы будет легко диагностировать и исправлять.
PS: в настоящее время я работаю над платежной системой EMV (SDK) и должен был вести учет транзакций, сначала я использовал SQLite3 для этой цели, но позже переместил свою реализацию в FMS, потому что были временные проблемы с базой данных, и было трудно отлаживать из них наиболее распространенным является код ошибки 21 в SQLite3, для которого доступна наименьшая помощь, во-вторых, трудно обнаружить утечки памяти, которые новичок легко создает.
Короче говоря, если ваша база данных не очень велика, проста в управлении и вы можете спроектировать структуру на основе разделителей, я бы посоветовала вам использовать FMS, но убедитесь, что вы сделали ее «ХОРОШО СТРУКТУРИРОВАННОЙ».
detector