База данных против плоских файлов

Ответ 1

• Базы данных могут обрабатывать запросы задач, поэтому вам не нужно ходить над файлами вручную. Базы данных могут обрабатывать очень сложные запросы.
• Базы данных могут обрабатывать задачи индексирования, поэтому, если такие задачи, как получение записи с идентификатором = x может быть ОЧЕНЬ быстро
• Базы данных могут обрабатывать многопроцессорный/многопоточный доступ.
• Базы данных могут обрабатывать доступ из сеть
• Базы данных могут следить за данными Целостность
• Базы данных могут легко обновлять данные (см. 1))
• Базы данных надежны
• Базы данных могут обрабатывать транзакции и одновременный доступ
• Базы данных + ORM позволяют вам манипулировать данные очень дружелюбны к программистам.

Ответ 2

Это ответ, который я уже дал некоторое время назад:

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

Кроме того, ваш язык программирования, скорее всего, уже имеет встроенный модуль (или его легко создать) для конкретного анализа.

Если вам нужно много дополнений (INSERTS?) И последовательный/мало доступа, мало/нет параллелизма, файлы - это путь.

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

С SQLite3 можно добиться многого, что является чрезвычайно легким (до 300 КБ), совместимым с ACID, написанным на C/C++ и вездесущим (если оно еще не включено в ваш пример языка программирования -for Python-, несомненно, есть один доступный). Это может быть полезно даже для файлов БД размером до 140 терабайт или 128 тибибайт (ссылка на размер базы данных), а может и больше.

Если ваши требования куда больше, даже обсуждения не будет, перейдите на полноценную RDBMS.

Как вы говорите в комментарии, что "система" - это просто набор скриптов, вам следует взглянуть на pgbash.

Ответ 3

Не создавайте его, если его можно купить.

Я недавно услышал эту цитату, и она действительно кажется подходящей. Спросите себя об этом... Сколько времени потрачено на обработку части вашего приложения? Я подозреваю, что было потрачено довольно много времени на оптимизацию этого кода для производительности. Если вы все время использовали реляционную базу данных, вы потратили бы значительно меньше времени на обработку этой части вашего приложения. У вас было бы больше времени для истинного "делового" аспекта вашего приложения.

Ответ 4

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

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

У них больше возможностей; базы данных могут позволить многим пользователям читать/писать одновременно.

С ними гораздо сложнее работать, когда они настроены.

Ответ 5

Базы данных полностью.

Однако, если вам все еще нужно хранить файлы, у вас нет возможности использовать новую RDBMS (например, Oracle, SQLServer и т.д.), чем просматривать XML.

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

Я настоятельно рекомендую БД, но если вы не можете пойти по этому маршруту, XML будет вторым.

Ответ 6

Как насчет нереляционной (NoSQL) базы данных, такой как Amazon SimpleDB, Tokio Cabinet и т.д.? Я слышал, что Google, Facebook, LinkedIn используют их для хранения своих огромных наборов данных.

Можете ли вы рассказать нам, если ваши данные структурированы, если ваша схема исправлена, если вам нужна легкая реплицируемость, если важно время доступа и т.д.?

Ответ 7

Какие типы файлов не упоминаются. Если это медиа файлы, продолжайте с плоскими файлами. Возможно, вам просто нужна БД для тегов и какой-то способ связать "внешние BLOB" с записями в БД. Но если вам нужен полнотекстовый поиск, другого пути нет, кроме как перейти на полную БД.

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

Разница между базой данных и плоскими файлами приведена ниже:

• База данных обеспечивает большую гибкость, тогда как плоский файл обеспечивает меньшую гибкость.

• Система баз данных обеспечивает согласованность данных, тогда как плоский файл не может обеспечить согласованность данных.

• База данных более безопасна над плоскими файлами.

• Поддержка базы данных DML и DDL, тогда как плоские файлы не могут поддерживать их.

• Меньше избыточности данных в базе данных, тогда как избыточность данных в плоских файлах.