txt файл вместо БД
Опубликовано Виктор в 09.07.2009 в 23:24
Вопрос ради интереса. Постоянно пишут про всякие дыры в БД, SQL иньекции и прочее. Вот есть текстовый файл. Почему не использовать их. Написать код который читает, пишет обрабатывает данные из этого файла и работать. Ну например небольшой форум, голосование, гостевую книгу, небольшой интернет - магазин сделать. Никаких же ведь инъекция там не сделать если правильно выставить и раздать права. Или я не прав? Наверняка есть какие - то наработки в данной тематике, хотелось бы обсудить. Понятно, что СУБД работает быстрее, да и удобнее запрос писать. Не является ли более надежным использовать текст. файл, там где объемы информации не такие большие.
Заранее спасибо.
В текстовый файл нельзя писать одновременно, нет механизма транзакций и т.д.
одновременно в один текстовый файл может писать только 1 пользователь.....представь такую картину в сети.....открываешь ты пустой текстовый файл и твой сосед тоже....каждый делает по одной записи в первое поле.....и каждый сохраняет.....вот кто последний сохранит - тот и перезапишет файл:))))) нет немного не прав....представь что твоя СУБД это деревянный ящик на гвоздях.....пока ты будешь мучаться с гвоздодёром, то приедет более умный человек и утащит его на погрузчике:):):):) проблема не только в sql-инъекциях....прогугли инет - межсайтовый скриптинг, социальная инженерия, сниферы, обход файерволов.....и многое другое, что так же может стырить твою БД даже если у неё все функции чётко описаны и ненужные аргументы закомментированы
> Наверняка есть какие - то наработки в данной тематике, хотелось бы обсудить.
Зайди на - там таких наколеночных скриптов с текстовыми файлами вместо БД - хоть жопой ешь.
> Не является ли более надежным использовать текст. файл
Не является ли более надёжным писать надёжный код?
Логично, что добавление записей, например, шеллом, будет через '>>', изменение через sed и т.д. Невозможность одновременного редактирования не проблема.
>>Логично, что добавление записей, например, шеллом, будет через '>>', изменение через sed и т.д.
ниразу не логично.. Может понадобиться в середине файла что-то изменить.
)) можно. (ответ на вопрос темы)
реализация.
для полноценной базы необходима поддержка чтения-записи-замены записей on-demand. реализация - heap или дерево время исполнения.
для предотвращения блокировок - механизм транзакций и сессий.Запись и чтение вне транзакций.
ИМХО, никто не запрещал вязать СУБД с файлом, текстовым в том числе. СУБД и БД - разные понятия. Или, как тогда работают XML-ные базы?)))
Все что ты добьешься, реализовывая такую базу, просто напишешь свою кустарную, крошечную СУБД, которая для хранения данных будет использовать текстовый файл, вместо структурированного. В итоге: полуживая субд, с ущербными возможностями, но с количеством дыр превышающим оное у фирменных аналогов. Как уже разумно заметили выше. Нужно просто напросто следить за тем, что скармливаешь движку БД и будет тебе счастье. А реализовать все проверки и зачитски куда быстрее и проще, чем реализация всей субд. ;)
>ниразу не логично.. Может понадобиться в середине файла что-то изменить.
sed, блять.
>sed, блять.
не заметил
Спасибо за ответы. Доходчиво. Краткий вывод: использование текстового файла - это написание примитивной СУБД. Особой пользы не принесет, а проблем добавит и времени отнимет.
что-то делать самому всегда создаёт проблем и время отнимает :D
ну по моему тут никто не говорил, что это НЕЛЬЗЯ делать....просто это не целесообразно и опасно
А вообще, файлы со счетов, всё-таки, сбрасывать не стоит. В некоторых случаях их использование может быть более эффективным, чем СУБД. Например, при хранении больших древовидных структур с примитивными нодами они могут очень даже помочь. Только, естественно, не в одном файле, а по файлу на ноду. В таком случае роль СУБД сыграет ФС. А если учесть, что ФС, как правило, работают на уровне ядра, скорость работы такой системы может оказаться на порядки быстрее.
Артём, поддерживаю но и дополню.
Файловая система (даже в случае RAID) на порядок медленне чем структура в ОЗУ. Посему счёту фс используют только в конечных загрузках и сохранениях таблицы/базы.
Результат продуктивности (время запрос-ответ) базы можно повысить только при использования экзо-ядра (минимизация системных вызовов). И даже такой шаг повысит производительность СУБД на 5-9%. Как в случае с обыкновенной базой, так и с "базой в файле".
Реализация последней кстати применима в embedded системах с ограничениями ОЗУ а также в случаях нужды жёсткого функционала БД или экстравагантной специфике её структуры (что иногда на порядок повышает продуктивность).
> Файловая система (даже в случае RAID) на порядок медленне чем структура в ОЗУ.
Не забываем про рамдиски:-)
> Не забываем про рамдиски:-)
Да а ещё про квантовые компютеры....
Рамдиски с файлами на самом деле довольно часто используются для подобных целей.
то что вы говорите называется типизированными файлами, их использовать очень просто. типизированный файл - это просто массив переменых любого типа.