Какие данные лучше хранить в MySQL?

Создаётся типа социальной сети. Пользователи могут заливать туда и текстовый контент и любые другие файлы. Под текстовым контентом я имею ввиду сообщения, сообщений может быть очень много(особенное в чате), и длина сообщений самая разная.

Пытаюсь думать логически:
Файловая система условно говоря представляет собой упрощенную субд с одной б.д. и таблицей в ней, в которой:
1.предопределенные поля:
id_файла (первичный ключ)
локальное_имя_имя_файла (уникален в пределах папки),
контент_файла - типа BLOB(если null - то это папка а не файл)
id_папки - папки в которой он надится
время_последней_правки_файла
права_доступа
... и так далее
2.она допускает сортировку по полям(кроме контент файла),
индексы - все поля(кроме контент_файла).
3.операции манипуляции данными осуществляются путём файловых функций пхп и
обработки в пхп массивов из файлов.

С файловой системой сравнивается МySQL с той же таблицей и с SQL запросами из пхп по основным файловым функциям(получение списка файлов в папке, получение контента в файле и др..)

И в этом случае вопрос сводится к тому: какая из этих двух субд с такой таблицей работает шустрее и экономичнее(по памяти), по каким операциям и при каких размерах полей контент_файла, и колличестве записей в таблице?

maximushka
Как можно писать большой проект и не знать азов.
Вообще понимаешь суть использования SQL и преимущества

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

MySQl а вторая? Вторая "СУБД" - это файлы? - в кавычки принципиально взял.


Что за бред? Не позорься.




Этот вопрос задается на тестировании inphp.org . Судя из твоих слов - ответ: "Недостаток оперативной памяти/производительности хоста".

P.S. В общем лучше почитай еще документацию и вообще попробуй понять для чего используют ту же mysql. И сразу все встанет на свои места.

Не совсем, файловая система, с функциями для обращения к её содержимому - базе данных - файлам, папкам.


Вот именно файловая система она и поддреживает ИСПОЛЬЗОВАНИЕ базы данных, а база данных в этом случае будет состоять из одной таблицы, записи которой - файлы и папки.
Да, она не поддерживает создание и управление, но речь здесь идёт лишь об использовании.


Из перечисленного - безусловно необходимость сложных сортировок и выборок.
Но тут речь о другом: менее главном для базы данных - о разграничении данных и несложных выборках с изменениями данных, и сложность - в рамках одной вышеприведенной таблицы.

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


Интересно на тебя посмотреть, когда 10 человек одновременно будут править твой файл, вот интересно на сколько красивый будет баг)))
В общем не переливай из пустого в порожнее, сначала определись, что ты будешь делать, а потом и думай с использованием чего. Если мне нужно хранить данные которые редко меняются, которых мало и с которыми не придется работать в плане постоянного изменения сортировки и т.д. - то я использую файлы, все остальные случаи БД.

P.S. MySQL основана так же на файлах, но почитай, что там в действительности происходит и т.д. В общем для большой работы нужно использовать базы данных.

Не надо такие слова писать.Ну если только очень условно.Речь о той таблице, которая описана по пунктам?
Вопрос поставлен не корректно.
Перечисленный функционал можно реализовать самому.
Плюс - можно хранить данные в структурах, которые эффективны для ваших конкретных целей.
Минус - вряд ли вы сделаете лучше, чем есть в готовой СУБД.

Вообще вопросы про что лучще: БД или файлы отпадают, если азы изучены и поняты.

Вот за эту фразу спасибо - она - ближе к делу.


Про велосипед - я так понял вы имели ввиду реализацию файловой системы в MySQL вышеприведенной таблицей? Ладно не буду, хотя мне всегда интуитивно казалось, что допустим 100 тысяч записей в одной таблице - это нормально, а 100 тысяч файлов в одной папке на виртуальном хосте, пусть даже по 1 килобайту каждый, уже излишний напряг для файловой системы. Это подозрение из за того, что я когда провожу синхронизацию файлов у себя на компе между двумя ж. дисками, то знаю как долго составляется список синхронизируемых файлов, для веба - это уже ни в какие рамки не влезет, вот и подумал что может MySQL скорее будет.


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


Базы данных используют почти все сайты, но вот мне не кажется что все из этих сайтов используют сложные запросы. В основном мне кажется простые: выборка по условию в полях, добавление записи, удаление и обновление. А ведь именно сложые запросы являются главным фактором использования как было написано в приведенной вами цитате.
(Добавление)

Ну значит нас в универе так плохо учили. Или учебники плохо написаны. Но сколько не изучаю базу данных вопрос всё еще не отпадает.
Да именно - по той одной таблице. Ну то что не корректен с точки зрения русского языка не спорю, может и пропустил запятые. Но смысл такой: Никакой функционал по структурам не реализуется - уже есть файловая система и файловые функции. Так и вот, если я напишу в mysql такую таблицу, и реализую внутреннюю на MySQL файловую систему, то она будет быстрее функционировать чем реальная файловая система из пхп. И в каких случаях быстрее.

(Отредактировано автором: 07 Марта, 2011 - 19:56:18)

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

Не стоит верить всему, что говорят в учебных заведениях, нужно принимать во внимание, а потом 100 раз перепроверить, а потом еще и протестировать.


И отвечу в общем на все вопросы, Sql работает гораздо быстрее чем файлы. А сортировку и т.д. лучше производить одной строчкой, а не мучить весь код.

А еще прочти про использование индексов в таблице, что они дают, да и вообще рекомендую почитать подробней о оптимизации SQL запросов, а там будет и понятно, на сколько быстрее работает SQL

Вот пожалуй действительно хороший совет. Напишу своё задуманное и выясню, сравню как оно по времени. А то конкретных ответов по вопросу тут так и нельзя получить, все на банальности ссылаются.. на индексы, я о них и так несколько раз читал и знаю толк, но есть уверенность что в файловой системе тоже есть индексы, т.к. в проводнике файлы в папке без проблем сортируются по разным полям и по дате создания и по имени файла, и по размерам и по другим...
Пока что одно кажется достоверным: плюс файловой системы перед субд в том что извлечение записи(файла) из первой по ключу(пути с именем файла) запросом GET (без посредника PHP) происходит как утверждается в разных статьях рунета в разы быстрее, и еще интуитивно кажется хранение текстовой информации в файлах даёт преимущества в оптимизации для поисковых систем при раскрутке сайтов.

maximushka
ПС не знает где ты хранишь данные, может вообще на луне, поэтому на раскрутку никак не влияет.
А по поводу SQL оптимизации лучше почитай, там много доводов в пользу SQL.

Бытрее. Но не в разы а чуть-чуть.Не дает. Поисковик видит ссылку, открывает, индексирует. Он не знает и ему все равно, как организовано хранение данных. Он видит то, что ему отдал сервер.Ну если достаточно индексов по параметрам файла, то да. И если достаточно параметров файла.
Но сделать без ухищрений JOIN чуть сложнее.
А самое интересное - это многопользовательская работа с файлами. Блокировать весь файл - это не круто. Одному скрипту понадобится менять начало файла, а другой, которому положить на это начало, которому нужен конец файла будет ждать впустую.
И еще можно написать большую кучу вещей касательно блокировок и транзакций, которые самостоятельно вы делать будете достаточно долго и натыкаясь на новые увлекательные косяки.

Тут ни какие не банальности, тут все по делу.