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

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

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

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

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

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


sql flat-file
person MichaelICE    schedule 14.09.2009    source источник

Ответы (5)


arrow_upward
1
arrow_downward

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

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

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

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

person HLGEM    schedule 14.09.2009

arrow_upward
1
arrow_downward

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

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

person alex    schedule 14.09.2009

arrow_upward
1
arrow_downward

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

  • Совместное использование данных: как несколько клиентов получат доступ к данным на общем ресурсе?
  • Резервное копирование/восстановление: синхронизация текста и "поиска"
  • Безопасность/разрешения на текстовые данные
  • Изменить аномалии
person gbn    schedule 15.09.2009

arrow_upward
0
arrow_downward

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

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

person D'Arcy Rittich    schedule 14.09.2009

arrow_upward
-2
arrow_downward

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

person Jack Straw    schedule 14.09.2009