SQL и плоские файлы ... в гармонии?

Question

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

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

Теперь представьте, что вы сохранили все свои данные для поиска в базе данных и имели поле указателя, указывающее на файл данных?

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

(блокировка, целостность данных в стороне), я уверен, что это было бы быстрее, но насколько, и стоит ли это делать?

Answer 1

Как и другие ответы ...

• Обмен данными: как несколько клиентов получат доступ к данным на общем ресурсе?
• Резервное копирование / восстановление: синхронизация текста и «поиск»
• Безопасность / разрешения на текстовые данные
• Изменение аномалий

Answer 2

Что ж, «Блокировка, целостность данных в стороне» должна означать более быструю систему. Если вы отбросите ограничения, вы должны улучшить производительность.

Но на практике я не думаю, что это будет быстрее. За СУРБД много времени, и поэтому они быстры. Несомненно, нереляционные базы данных работают лучше, чем они, в высокопараллельных ситуациях и сценариях, которые используют, например, их качества. Однако ваша идея не предлагает улучшения, такого как использование параллелизма ... любое преимущество в производительности может быть получено за счет снижения качества СУБД ...

Answer 3

Ну, вы часто хотите делать что-то в запросах, помимо поиска по данным. Например, вы можете не выполнять поиск в поле с именем cost_center, но у вас может быть запись состояния, которая обрабатывает вещи по-разному в зависимости от информации в поле. Или вам может потребоваться объединить информацию вместе. Вы можете обновить одно поле на основе информации в другом поле. Вы можете не искать поле сегодня и искать его завтра.

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

И, честно говоря, вы никогда не должны даже рассматривать "целостность данных в стороне". Если у вас нет целостности данных, у вас нет данных.

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

Answer 4

BTrieve было важно то, что вы описываете. В дни DOS это была очень быстрая база данных.

Answer 5

Нет необходимости реализовывать базу данных SQL только для выполнения поиска. Многие приложения хранят свои данные в XML, и вы можете осуществлять поиск различными способами, например, с помощью Lucene. То, насколько быстро все это зависит, зависит от количества данных и от того, как вы их структурируете - как база данных.

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