в чем хранить в файлах или в базе?

[-=KPOT=-]

в чем хранить в файлах или в базе?

Доброго все времени суток
Нужен совет.
Делаю себе диплом "система тестирования" ну там типа тесты преподов которые преднозначены для промежуточного тестирования студентов.
Так вот на этапе разработки возник вопрос где хранить тесты в базе или в фаилах (а ссылки на них вбазе)? Где правильней?
Советы прошу аргументировать.

 

[Panchous]

в базе можно хранить ВСЕ:
и тесты, и вопросы, и ответы, и учителей, и т.д.

 

[_RVK_]

-=KPOT=-
Именно в базе. Потому что:

+
Быстрее
Надежнее
Гибче
Проще
Безопаснее

Могу еще привести аргументов.

 

[Sad Spirit]

Автор оригинала: Diesel
Именно в базе. Потому что:

+
Быстрее
Надежнее
Гибче
Проще
Безопаснее

Могу еще привести аргументов.

Нет уж, нет уж. Сначала поясни эти аргументы. Вот прикопаемся, например, к слову "Быстрее". Очевидно, что данные, которые ты кладёшь в базу, в конечном итоге сама база будет хранить в файлах. Так что заставляет тебя думать, что работа с файлами через неслабых размеров прокладку будет быстрее, чем работа с файлами напрямую?..

И аналогично --- по всем пунктам, пожалуйста.

 

[SelenIT]

имхо, для начала не мешало бы уточнить, что собой представляют тесты

 

[Кром]

-=KPOT=- в поиске по форуму смотрел:
http://phpclub.ru/talk/search.php?s=&action=showresults&searchid=367118&sortby=lastpost&sortorder=descending

 

[ForJest]

-=KPOT=-
Если у тебя возник этот вопрос, значит тебе лучше хранить их в базе. Т.к. СУБД решит многие из твоих проблем по организации работы с данными. Правда для этого тебе придётся многому научиться. Но при хранении данным в файлах тебе придётся научиться тоже довольно многому.
За говорит то, что СУБД подход и полученные в связи с этим знания позволят решать более широкий класс задач, чем реализованное решение на файлах.

 

[_RVK_]

Sad Spirit
Это экзамен что ли?
1. Быстрее.
Изначально БД созданы для хранения данных. Поэтому в них применяются различные приемы для ускорения доступа к данным. Такие как, кеширование, индексация и буферизация. Хотя таблица БД это такой же файл, но часть его, все время хранится в памяти, поэтому доступ к данным происходит гораздо быстрее, нежели к данным в обычном фйле. Стоит также упомянуть, что для работы с БД существует специальный язык SQL. Поэтому оснавная чать работы по выборке данных происходит на стороне сервера БД, где программисты уже постарались применить самые быстрые алгоритмы работы с записями в файлах....

2. Надежнее.
В СУБД сохранность и целостность данных контролирует сама субд, которая содержит ряд средств для востанавления и оптимизации данных а БД. Клиент-серверная архитектура большенства СУБД обеспечивает безопасный одновременный доступ к данным, сразу нескольких пользователей. А поддержка транзакций, большенством СУБД, позволяют, в случае ошибки, вернуть данные в первоначальный вид.

3. Гибче
Реляционная модель позволяет создавать давольно гибкие и легко расширяемые БД. Это позволяет легко расширять функциональность приложения, без значительного изменения кода.

4. Проще.
Язык SQL предоставляет простые средства для работы с БД. Выборка, удаление, обновление и т.д. данныых осучествляются одним запросом, и отпадает необходимость в написании сложных алгоритмов для работы с данными.

5. Безопаснее
СУБД предоставляют ряд средств для защиты данных от несанкционированного доступа.

Это так, кратко. Хотя на эту тему можно диплом написать

 

[Sad Spirit]

Автор оригинала: Diesel
Sad Spirit
Это экзамен что ли?

Нет, это элементарный вопрос на понимание.

1. Быстрее.
Изначально БД созданы для хранения данных. Поэтому в них применяются различные приемы для ускорения доступа к данным. Такие как, кеширование, индексация и буферизация. Хотя таблица БД это такой же файл, но часть его, все время хранится в памяти, поэтому доступ к данным происходит гораздо быстрее, нежели к данным в обычном фйле. Стоит также упомянуть, что для работы с БД существует специальный язык SQL. Поэтому оснавная чать работы по выборке данных происходит на стороне сервера БД, где программисты уже постарались применить самые быстрые алгоритмы работы с записями в файлах....

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

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

2. Надежнее.
В СУБД сохранность и целостность данных контролирует сама субд, которая содержит ряд средств для востанавления и оптимизации данных а БД. Клиент-серверная архитектура большенства СУБД обеспечивает безопасный одновременный доступ к данным, сразу нескольких пользователей. А поддержка транзакций, большенством СУБД, позволяют, в случае ошибки, вернуть данные в первоначальный вид.

При этом в большинстве СУБД данные всё равно хранятся в файловой системе. Следовательно, надёжность хранения данных не может быть выше, чем надёжность нижележащей файловой системы, так? Утилита fsck является замечательным средством восстановления данных, а команда flock обеспечивает одновременный доступ к данным сразу нескольких пользователей.

Транзакции же на самом деле никому не нужны --- я это в (старой) документации MySQL прочитал.

3. Гибче
Реляционная модель позволяет создавать давольно гибкие и легко расширяемые БД. Это позволяет легко расширять функциональность приложения, без значительного изменения кода.

4. Проще.
Язык SQL предоставляет простые средства для работы с БД. Выборка, удаление, обновление и т.д. данныых осучествляются одним запросом, и отпадает необходимость в написании сложных алгоритмов для работы с данными.

Вот этими пунктами и стоило ограничиться.

5. Безопаснее
СУБД предоставляют ряд средств для защиты данных от несанкционированного доступа.

Файловая система позволяет выставить права на файлы.

Это так, кратко. Хотя на эту тему можно диплом написать

на эту тему книги написаны. если б их ещё и читали...

 

[_RVK_]

Sad Spirit твои замечания верны, и я о них, конечно, знаю. Но если применить все эти ухищрения для работы с файлами (индексация, востановление, алгоримы выборки, одновременный доступ и т.д.) то получится своя миниСУБД. Это куча кода. Эти решения, зачастую, не кросплатформенны. Одна ФС поддерживает права на файлы, другая нет. В одной ОС есть специальные утилиты, в другой нет.... Так зачем изобретать велосипед? Бери и пользуйся.

 

[-=KPOT=-]

всем спасибо за советы вопрос решился
храним в базе

Автор оригинала: ForJest
-=KPOT=-
Правда для этого тебе придётся многому научиться. Но при хранении данным в файлах тебе придётся научиться тоже довольно многому.

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

1 тест будет представлять из себя порядка 50 (а может иболее вопросов) с максимумом в 20 ответов на вопрос (надеюсь хватит ;-))

-~{}~ 11.10.04 13:42:

и еще один вопросик в каком поле хранить сам тест?
у меня пока просто text на сколько его хватит?

 

[Фанат]

Такие вещи принято смотреть самостоятельно, в документации.
Хотя, конечно, ман по мускулю - далеко не идеальный пример нафигации.
На - http://dev.mysql.com/doc/mysql/ru/Column_types.html и решай сам, подойдет или нет

 

[Sad Spirit]

Автор оригинала: -=KPOT=-
и еще один вопросик в каком поле хранить сам тест?
у меня пока просто text на сколько его хватит?

Хранить надо не "тест", а отдельные вопросы. и таки да, если нет явно заданных ограничений на длину вопроса, то в поле типа text.

 

[Alexandre]

Именно в базе. Потому что:
+
Быстрее

При использовании кешеров, время выборки данных из файла несравнимо мало по сравнению с БД.

БД надежнее и безопастнее - согласен. Хотя, при размещение файла вне WEB пространства, его безопастность сравнима с безопастностью хранения в БД.
(безопастность с точки зрения несанкционированного доступа)

Если рассматривать - безопастность с точки зрения хранения, то архивация и откат в случае сбоев что баз - что файлов - имеет одим порядок.

При мультидоступе могут возникнуть конкурентные проблемы? но файлы же только на чтение.

Несмотря на это:
Выбор БД - правильное решение.

 

[-=KPOT=-]

Автор оригинала: Sad Spirit
Хранить надо не "тест", а отдельные вопросы. и таки да, если нет явно заданных ограничений на длину вопроса, то в поле типа text.

вот а вот за этот совет спасибо (как минимум пару троику проблем снял). как только сразу не догнал