Здравствуйте, DSD, Вы писали:
R>>Не согласен. Ресурсов нужно имхо значительно меньше, чем для обращения к файловой стистеме. Спор безосновательный (на каждое Ваше утверждение могу предлоить контрдовод). Нуже бенчмарк. Неопнятно только, как его организовать. DSD>То есть, по вашему мнению, сервер БД к файловой системе не обращается, так? DSD>Так вот, спешу вас разочаровать, он и к fs обращается, и все вышеперечисленное делает. И как я сказал, чуть снижается ресурсопотребление только за счет некоторого кеширования данных. DSD>Что же касается хранения данных в своем формате и работы с ними, то тут быстродействие большей частью зависит от того, на каком языке вы программируете данное приложение. Ясен пень, что сервера БД пишутся чаще всего на чистом С или С++.
Я представляю себе, как работает бд, в т.ч. и MySQL. Тем не менее на собственном опыте почувствовал, что она быстрее (во всяком случае для моих задач), чем файловая система.
Примечание: мои задачи =))) это в основном как раз цмс, форум, в общем поддержка сайта.
R>>btw по поводу сопровождения: бд сопровождать гораздо удобнее, если есть правильные инструменты для этого. DSD>С этим не спорю. Однако иногда и тут бывают грабли. Нет ничего идеального
Ну с этим трудно спорить, но все таки, если есть время, гораздо удобнее написать инструмент, чем потом мучаться с совместимостью с чужими.
Здравствуйте, DSD, Вы писали: DSD>К примеру, здесь на форуме многие сами используют и пытаются другим советовать функции типа get_file_contents или что-то вроде того, мол типа такая крутая функция, одним вызовом можно получить любой файл, локальный, сетевой или вообще по URL. Но никто не задумывается, что единственное преимущество этой функции — это ее универсальность, т.е. удобство делать все и в разных ситуациях одним вызовом. Зато при этом в каждом локальном случае эта функция делает туеву хучу разной ненужной работы, как то парсинг аргумента, чтобы получить представление о местоположении файла(локал, сеть, инет), выделение в памяти буффера под содержимое(хотя далеко не всегда нужен весь контент файла), ну и т.п. Плюс ко всему, возможно с локальными файлами она внутри себя работает в текстовом режиме, что в таком случае тоже сказывается на ее производительности. DSD>Ясен пень, тут будут тормоза.
Уважаемый DSD!
Во-первых, file_get_contents()
Во-вторых, удобство данной функции как раз и заключается в том что она бестрее чем какая либо другая функция/конструкция вычитает файл в строку.
Объясняю, что получится, если идти другим путем.
Т.е., например альтернатива:
/*$filepath - url или путь к файлу (практически все пхп функции которые работают с файлом принимают совершенно
нормально url)*/
$content = "";
$content_strings = file( $filepath);
foreach( $content_strings as $string) {
$content .= $string;
}
Хотя в данном случае куда лучше
$content = join( " ", file( $filepath));
Но я уверен, что найдется достаточное количество и тех, кто напишет именно так как в первом случае.
Если говорить о ПХП то его функции работы с файлами все универсальны в том плане, что могут абсолютно нормально принимать URL как аргумент. И это логично — это ВЕБ программирование. Так что твои доводы пе этому поводу весьма
неубедительны.
Вопрос скорости. Любой ПХП код исполняется медленее, чем нативный. Поэтому логичнее с точки зрения быстродействия использовать встроенную функцию, а не писать такую же свою. Поэтому, если надо вычитать весь контент файла в строку file_get_contents — самый быстрый и удобный способ это сделать.
ЖуК>Во-первых, file_get_contents()
Это не принципиально. Я не пишу на PHP. И в доку не лазил, чтоб посмотреть, как она точно называется. Главное, чтобы все поняли, о чем речь.
ЖуК>Во-вторых, удобство данной функции как раз и заключается в том что она бестрее чем какая либо другая функция/конструкция вычитает файл в строку.
Речь немного не о том, как вычитать файл в строку, а о том, как вообще быстрее работать с файловой системой.
ЖуК>Объясняю, что получится, если идти другим путем. ЖуК>Т.е., например альтернатива: ЖуК>
ЖуК>/*$filepath - url или путь к файлу (практически все пхп функции которые работают с файлом принимают совершенно
ЖуК>нормально url)*/
ЖуК>$content = "";
ЖуК>$content_strings = file( $filepath);
ЖуК>foreach( $content_strings as $string) {
ЖуК> $content .= $string;
ЖуК>}
ЖуК>
ЖуК>Хотя в данном случае куда лучше
ЖуК>
ЖуК>$content = join( " ", file( $filepath));
ЖуК>
ЖуК>Но я уверен, что найдется достаточное количество и тех, кто напишет именно так как в первом случае.
ЖуК>Еще вариант:
ЖуК>
С Вами бесполезно спорить о производительности, пока Вы не будете себе четко представлять разницу между fread и fgets(в частности как они работают внутри, а не только разницу в синтаксисе вызова), между работой с файлами в текстовом и бинарном режимах, пока вы не будете считать память, занимаемую каждой Вашей переменной в программе/скрипте, а так же память и ресурсы, занимаемые разными системными и библиотечными функциями в процессе их работы.
ЖуК>Если говорить о ПХП то его функции работы с файлами все универсальны в том плане, что могут абсолютно нормально принимать URL как аргумент. И это логично — это ВЕБ программирование. Так что твои доводы пе этому поводу весьма ЖуК>неубедительны.
Вот по теме данной ветки как раз лишнюю часть, отвечающую за работу с URL, лучше бы из этих функций выкинуть.
ЖуК>Вопрос скорости. Любой ПХП код исполняется медленее, чем нативный. Поэтому логичнее с точки зрения быстродействия использовать встроенную функцию, а не писать такую же свою. Поэтому, если надо вычитать весь контент файла в строку file_get_contents — самый быстрый и удобный способ это сделать.
ЖуК>В чем я неправ?
Неправы Вы в том, что если нужно вычитать не весь файл, а только его часть, Вы будете применять file_get_contents, вычитывая его в память, а потом делать всякие substr и т.п. С чего я взял, что Вы будете делать именно так? Да вот с этого: http://www.rsdn.ru/Forum/?mid=272955
Здравствуйте, Rumata, Вы писали:
R>Здравствуйте, DSD, Вы писали:
R>>>Не согласен. Ресурсов нужно имхо значительно меньше, чем для обращения к файловой стистеме. Спор безосновательный (на каждое Ваше утверждение могу предлоить контрдовод). Нуже бенчмарк. Неопнятно только, как его организовать. DSD>>То есть, по вашему мнению, сервер БД к файловой системе не обращается, так? DSD>>Так вот, спешу вас разочаровать, он и к fs обращается, и все вышеперечисленное делает. И как я сказал, чуть снижается ресурсопотребление только за счет некоторого кеширования данных. DSD>>Что же касается хранения данных в своем формате и работы с ними, то тут быстродействие большей частью зависит от того, на каком языке вы программируете данное приложение. Ясен пень, что сервера БД пишутся чаще всего на чистом С или С++. R>Я представляю себе, как работает бд, в т.ч. и MySQL.
Сомневаюсь, судя по Вашим постам.
R>Тем не менее на собственном опыте почувствовал, что она быстрее (во всяком случае для моих задач), чем файловая система. R>Примечание: мои задачи =))) это в основном как раз цмс, форум, в общем поддержка сайта.
Странно, мои подобные задачи стали работать гораздо быстрее, когда я их переписал с варианта на MySQL на вариант с использованием файловой системы и кеша.
Вам не кажется это странным: моя файловая система работает быстрее, чем MySQL, который, в свою очередь, работает быстрее, чем Ваша файловая система?
И еще. Вы действительно почувствовали, что БД работает быстрее, чем FS на своем опыте? То есть Вы пробовали и так, и так, да?
Я к чему это спросил: редко кто делает все на FS, а потом переходит на БД. Большинство сразу пишут на БД, а о FS-вариантах судят только по тому, что слышали от других. Поэтому хочу убедиться, что Вы не один из них и не голословно утверждаете сей факт.
Еще я знаю, что большинство веб-программистов(или веб-мастеров, как их правильнее назвать) на файловой системе данные хранят двумя способами: либо одна запись = один файл, либо в одном файле, но в текстовом, немного похожем на структуру ini-файла. То есть делают удобно для чтения человека, а не машины. И после этого становится понятным, откуда тормоза.
Я же говорю о нормальном бинарном хранилище данных. Записи отдельно, индексы для них отдельно. Хотя бы в таком простом варианте.
Вот именно так в вебе редко кто пишет(типа сложно и неудобно). А стоило бы...
Ведь не функции чтения с диска тормозят. Не их мы сравниваем(кстати, MySQL, как и другие сервера БД, тоже хранит данные на диске).
Здравствуйте, DSD, Вы писали:
DSD>Здравствуйте, Rumata, Вы писали:
R>>Здравствуйте, DSD, Вы писали:
R>>>>Не согласен. Ресурсов нужно имхо значительно меньше, чем для обращения к файловой стистеме. Спор безосновательный (на каждое Ваше утверждение могу предлоить контрдовод). Нуже бенчмарк. Неопнятно только, как его организовать.
О чём спор ?
Файловая система предназначена для хранения файлов, именно поэтому ей и пользуются для хранения файлов. БД предназначены для хранения данных и в БД хранить данные эффективнее чем в файловой системе, а в файловой системе эффективнее хранить именно файлы.
Я вообще слабо себе представляю задачу в которой я бы выбирал хранить ли файлы в БД или в файловой системе, об этом даже вопрос вставать не должен, а иначе пора заниматься теорией.
З.Ы. Товарищ DSD в свете скорого выхода новой версии SQL сервера Yukon, ваши доводы о скорости файловой системы оказываются безосновательными.
Здравствуйте, Andir, Вы писали:
A>О чём спор ? A>Файловая система предназначена для хранения файлов, именно поэтому ей и пользуются для хранения файлов. БД предназначены для хранения данных и в БД хранить данные эффективнее чем в файловой системе, а в файловой системе эффективнее хранить именно файлы. A>Я вообще слабо себе представляю задачу в которой я бы выбирал хранить ли файлы в БД или в файловой системе, об этом даже вопрос вставать не должен, а иначе пора заниматься теорией.
Кстати, это правда, что в Windows Longhorn файловая система будет на базе данных сделана (где-то слышал )?
Здравствуйте, DSD, Вы писали:
DSD>И еще. Вы действительно почувствовали, что БД работает быстрее, чем FS на своем опыте? То есть Вы пробовали и так, и так, да? DSD>Я к чему это спросил: редко кто делает все на FS, а потом переходит на БД. Большинство сразу пишут на БД, а о FS-вариантах судят только по тому, что слышали от других. Поэтому хочу убедиться, что Вы не один из них и не голословно утверждаете сей факт.
Привожу простой пример, показывающий несостоятелность ФС-варианта:
Допустим у нас 1 запись на 1 файл. Допустим они (данные) хранятся в определенном формате. Допустим надо вывести название, скажем, каждого продукта, который хранится в файле.
Вопрос: насколько быстрее будет выбрать данные из базы нежели открывать каждый файл и выцарапывать оттуда название ?
И таких вариантов — вагон и маленькая тележка.
Вариант с написанием собственного хранилища данных не рассматриваем — ибо это будет написание своей базы, что противоречит начальным условиям задачи.
Я, по первости, тоже думал, что база это нифига не рулез, что надо все на файлах делать. В результате поимел такого гемороя — мама дорогая. Никому не советую. Даже убогий (в плане функциональности) MySQL на порядки выше по удобству работы перед файловой системой.
Здравствуйте, DSD, Вы писали:
ЖуК>>Во-вторых, удобство данной функции как раз и заключается в том что она бестрее чем какая либо другая функция/конструкция вычитает файл в строку. DSD>Речь немного не о том, как вычитать файл в строку, а о том, как вообще быстрее работать с файловой системой.
Нет! Речь как раз о том как быстрее вычитать файл. Я предлагал эту функцию именно для этой цели.
DSD>С Вами бесполезно спорить о производительности, пока Вы не будете себе четко представлять разницу между fread и fgets(в частности как они работают внутри, а не только разницу в синтаксисе вызова), между работой с файлами в текстовом и бинарном режимах, пока вы не будете считать память, занимаемую каждой Вашей переменной в программе/скрипте, а так же память и ресурсы, занимаемые разными системными и библиотечными функциями в процессе их работы.
Я уже начал замечать, что все думают о себе выше чем о других. Ну да бог с ним, я не гордый.
DSD>Этот код работает быстрее всех вышеприведенных:
Даже и не хочется проверять. Но вот работает ли он быстрее file_get_contents() я все-таки проверил. DSD, неужели так трудно понять, что всторенные функции работают быстрее, чем самописные??? Смотри сам — http://scripts.kiev.ua/site/examples/test.php. Именно по-этому я и предлагал использовать file_get_contents()
ЖуК>>Если говорить о ПХП то его функции работы с файлами все универсальны в том плане, что могут абсолютно нормально принимать URL как аргумент. И это логично — это ВЕБ программирование. Так что твои доводы пе этому поводу весьма ЖуК>>неубедительны. DSD>Вот по теме данной ветки как раз лишнюю часть, отвечающую за работу с URL, лучше бы из этих функций выкинуть.
А это уже не в наших силах. Напишите свой ПХП.
ЖуК>>Вопрос скорости. Любой ПХП код исполняется медленее, чем нативный. Поэтому логичнее с точки зрения быстродействия использовать встроенную функцию, а не писать такую же свою. Поэтому, если надо вычитать весь контент файла в строку file_get_contents — самый быстрый и удобный способ это сделать.
ЖуК>>В чем я неправ? DSD>Неправы Вы в том, что если нужно вычитать не весь файл, а только его часть, Вы будете применять file_get_contents, вычитывая его в память, а потом делать всякие substr и т.п. С чего я взял, что Вы будете делать именно так? Да вот с этого: http://www.rsdn.ru/Forum/?mid=272955
Вычитывать весь файл, чтобы узнать только его размер — крайне нецелесообразно.
И по поводу этой ветки. Во-первых, я предложил первое, что пришло в голову. Во-вторых, вопрос заключался в том, чтобы вычитаь размер файла, который находился по какому-то URL. filesize() не принимает параметр, который является URL.
Решение с заголовками, конечно же, более оптимальный вариант в данном случае. Но что касается того, как быстрее ВЫЧИТАТЬ ФАЙЛ В СТРОКУ — file_get_contents — самый быстрый способ.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, Andir, Вы писали:
A>>О чём спор ? A>>Файловая система предназначена для хранения файлов, именно поэтому ей и пользуются для хранения файлов. БД предназначены для хранения данных и в БД хранить данные эффективнее чем в файловой системе, а в файловой системе эффективнее хранить именно файлы. A>>Я вообще слабо себе представляю задачу в которой я бы выбирал хранить ли файлы в БД или в файловой системе, об этом даже вопрос вставать не должен, а иначе пора заниматься теорией.
WF>Кстати, это правда, что в Windows Longhorn файловая система будет на базе данных сделана (где-то слышал )?
Здравствуйте, DSD, Вы писали:
R>>Я представляю себе, как работает бд, в т.ч. и MySQL. DSD>Сомневаюсь, судя по Вашим постам.
Очень жаль. Ничем не могу помочь.
R>>Тем не менее на собственном опыте почувствовал, что она быстрее (во всяком случае для моих задач), чем файловая система. R>>Примечание: мои задачи =))) это в основном как раз цмс, форум, в общем поддержка сайта. DSD>Странно, мои подобные задачи стали работать гораздо быстрее, когда я их переписал с варианта на MySQL на вариант с использованием файловой системы и кеша.
Возможно Вы неудачно проектироали структуру бд.
DSD>Вам не кажется это странным: моя файловая система работает быстрее, чем MySQL, который, в свою очередь, работает быстрее, чем Ваша файловая система?
Кажется.
DSD>И еще. Вы действительно почувствовали, что БД работает быстрее, чем FS на своем опыте? То есть Вы пробовали и так, и так, да?
Да. Быстрее настолько, что при работе через фс пхп иногда вылетал по таймауту. Такая уж задача была.
DSD>Я к чему это спросил: редко кто делает все на FS, а потом переходит на БД. Большинство сразу пишут на БД, а о FS-вариантах судят только по тому, что слышали от других. Поэтому хочу убедиться, что Вы не один из них и не голословно утверждаете сей факт.
К моему несчастью мне далеко не сразу удалось попасть на хостинг с поддержкой бд, поэтому, например, я поначалу долго общался с такой штукой, как ubb, а потом перешел на vbb. Уж поверьте, на основе этих двух форумов я могу сравнить фс и бд.
DSD>Еще я знаю, что большинство веб-программистов(или веб-мастеров, как их правильнее назвать) на файловой системе данные хранят двумя способами: либо одна запись = один файл, либо в одном файле, но в текстовом, немного похожем на структуру ini-файла. То есть делают удобно для чтения человека, а не машины. И после этого становится понятным, откуда тормоза. DSD>Я же говорю о нормальном бинарном хранилище данных. Записи отдельно, индексы для них отдельно. Хотя бы в таком простом варианте.
К сожалению, не понял, Вашу мысль. Не могли бы Вы привести пример вида: в файле a.txt храним то, то и то в формате таком, в файле b.txt ...
DSD>Ведь не функции чтения с диска тормозят. Не их мы сравниваем(кстати, MySQL, как и другие сервера БД, тоже хранит данные на диске).
Повторяю еще раз: я в курсе, где хранит данные mysql.
btw честно говоря, я потерял нить, а что мы сравниваем?
Здравствуйте, ЖуК, Вы писали:
DSD>>Речь немного не о том, как вычитать файл в строку, а о том, как вообще быстрее работать с файловой системой. ЖуК>Нет! Речь как раз о том как быстрее вычитать файл. Я предлагал эту функцию именно для этой цели.
В данной ветке речь как раз о скорости работы с FS.
DSD>>С Вами бесполезно спорить о производительности, пока Вы не будете себе четко представлять разницу между fread и fgets(в частности как они работают внутри, а не только разницу в синтаксисе вызова), между работой с файлами в текстовом и бинарном режимах, пока вы не будете считать память, занимаемую каждой Вашей переменной в программе/скрипте, а так же память и ресурсы, занимаемые разными системными и библиотечными функциями в процессе их работы.
ЖуК>Я уже начал замечать, что все думают о себе выше чем о других. Ну да бог с ним, я не гордый.
Не о себе, а об осведомленности многих "других". О том, что не мешало бы знать, что делают разные, как им кажется, "системные" функции, прежде, чем писать, что быстрее, а что нет....
ЖуК>Даже и не хочется проверять. Но вот работает ли он быстрее file_get_contents() я все-таки проверил. DSD, неужели так трудно понять, что всторенные функции работают быстрее, чем самописные??? Смотри сам — http://scripts.kiev.ua/site/examples/test.php. Именно по-этому я и предлагал использовать file_get_contents()
Когда ты напишешь приложение, работающее с файлом, как с БД, ты поймешь, в чем разница...
И когда ты просто по возвращаемым заголовкам будешь определять размер, ты тоже поймешь, что это быстрее, чем прочитать весь файл...
DSD>>Вот по теме данной ветки как раз лишнюю часть, отвечающую за работу с URL, лучше бы из этих функций выкинуть. ЖуК>А это уже не в наших силах. Напишите свой ПХП.
Вот я на чистом Си и написал. И доволен. Сможете ли Вы так?
ЖуК>И по поводу этой ветки. Во-первых, я предложил первое, что пришло в голову.
Вот и плохо.
ЖуК>Во-вторых, вопрос заключался в том, чтобы вычитаь размер файла, который находился по какому-то URL. filesize() не принимает параметр, который является URL.
Как раз принимает. Но это абсолютно неудачный пример.
ЖуК>Даже и не хочется проверять. Но вот работает ли он быстрее file_get_contents() я все-таки проверил. DSD, неужели так трудно понять, что всторенные функции работают быстрее, чем самописные??? Смотри сам — http://scripts.kiev.ua/site/examples/test.php. Именно по-этому я и предлагал использовать file_get_contents()
Я говорил не о file_get_contents, а о всех "своих" функциях, которые Вы приводили в предыдущем посте.
И еще, Вы постите эту функцию(file_get_contents), совершенно не понимая, как она внутри работает. Единственное, чем Вы аргументируете, это то, что она "системная, и потому быстрее". То есть Вы можете выиграть спор только в тех случаях, где действительно это играет роль. В остальных случаях Вы даже обьяснить не сможете, почему быстрее работает тот или иной код.
Здравствуйте, DSD, Вы писали:
DSD>И еще, Вы постите эту функцию(file_get_contents), совершенно не понимая, как она внутри работает. Единственное, чем Вы аргументируете, это то, что она "системная, и потому быстрее". То есть Вы можете выиграть спор только в тех случаях, где действительно это играет роль. В остальных случаях Вы даже обьяснить не сможете, почему быстрее работает тот или иной код.
Товарищ DSD сомневаться в профессиональных качествах кого-либо на данном форуме запрещено правилами!!!
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, DSD, Вы писали:
DSD>>Здравствуйте, Rumata, Вы писали:
R>>>Здравствуйте, DSD, Вы писали:
R>>>>>Не согласен. Ресурсов нужно имхо значительно меньше, чем для обращения к файловой стистеме. Спор безосновательный (на каждое Ваше утверждение могу предлоить контрдовод). Нуже бенчмарк. Неопнятно только, как его организовать.
A>О чём спор ? A>Файловая система предназначена для хранения файлов, именно поэтому ей и пользуются для хранения файлов. БД предназначены для хранения данных и в БД хранить данные эффективнее чем в файловой системе, а в файловой системе эффективнее хранить именно файлы. A>Я вообще слабо себе представляю задачу в которой я бы выбирал хранить ли файлы в БД или в файловой системе, об этом даже вопрос вставать не должен, а иначе пора заниматься теорией.
А БД разве хранит данные не в файловой системе?
A>З.Ы. Товарищ DSD в свете скорого выхода новой версии SQL сервера Yukon, ваши доводы о скорости файловой системы оказываются безосновательными.
Во-первых, что такое Yukon? Во-вторых, не в файловой системе ли он хранит свои данные?
Здравствуйте, DSD, Вы писали:
A>>Файловая система предназначена для хранения файлов, именно поэтому ей и пользуются для хранения файлов. БД предназначены для хранения данных и в БД хранить данные эффективнее чем в файловой системе, а в файловой системе эффективнее хранить именно файлы. A>>Я вообще слабо себе представляю задачу в которой я бы выбирал хранить ли файлы в БД или в файловой системе, об этом даже вопрос вставать не должен, а иначе пора заниматься теорией. DSD>А БД разве хранит данные не в файловой системе?
Какая разница где она их хранит, хоть в оперативной памяти, здесь важна сама организация данных, я могу выбирать как представлять те или иные данные. Выделять в сущностях их атрибуты и использовать их. Файловая система не предназначена для хранения данных.
Очевидно, что на выборку 10000 (цифра взята с потолка) сущностей из базы данных и файловой системы и их обработку, времени будет тратится будет больше на файловой системе (парсинг строковых(бинарных и др.) данных хранящихся в файлах, читать один файл БД или 10000 файловой системы и т.д.). Организовать эффективное хранилище данных на файловой системе используя только собственно сами файлы вообще нельзя, минимально нужно будет особым образом размечать данные в файлах — а это уже прототип базы данных.
A>>З.Ы. Товарищ DSD в свете скорого выхода новой версии SQL сервера Yukon, ваши доводы о скорости файловой системы оказываются безосновательными. DSD>Во-первых, что такое Yukon? Во-вторых, не в файловой системе ли он хранит свои данные? Сюда. У него своя файловая система, заточенная для хранения реляционных данных (на самом деле это даже файловой системой в обычном понимании не является).
www.fag.pisem.net/parser.rar — там две вродебы самы последние версии, все без комментов. Строится простенькая объектная модель. Первая версия сначала читает урл в строку, потом парсит. Вторая пытается это делать по мере чтения. В любом случае модель выходит тока после полного распарсивания. Все таки медленоват стервец получился. А так, вроде багов незамечено. Жду отзывов.
ЖуК>Но что касается того, как быстрее ВЫЧИТАТЬ ФАЙЛ В СТРОКУ — file_get_contents — самый быстрый способ.
Попробовал я твой пример — быстрее fopen — 15 сек., get_contents — 17 сек.
Здравствуйте, Andir, Вы писали:
DSD>>А БД разве хранит данные не в файловой системе?
A>Какая разница где она их хранит, хоть в оперативной памяти, здесь важна сама организация данных, я могу выбирать как представлять те или иные данные. Выделять в сущностях их атрибуты и использовать их. Файловая система не предназначена для хранения данных. A>Очевидно, что на выборку 10000 (цифра взята с потолка) сущностей из базы данных и файловой системы и их обработку, времени будет тратится будет больше на файловой системе (парсинг строковых(бинарных и др.) данных хранящихся в файлах, читать один файл БД или 10000 файловой системы и т.д.). Организовать эффективное хранилище данных на файловой системе используя только собственно сами файлы вообще нельзя, минимально нужно будет особым образом размечать данные в файлах — а это уже прототип базы данных.
Стоп, стоп, стоп! Здесь Вы прицепились уже к самим терминам и конкретике. Речь шла не о разнице между БД и файловой системой как таковой. А шла речь об использовании либо СУБД(читай сторонний сервер БД) либо своего хранилища данных в файле/файлах, т.е. о директивном доступе к БД. А еще точнее, речь шла о скорости доступа к данным в этих двух способах. По крайней мере, я именно это имел ввиду.
Конечно, система клиент-сервер(как в случае с сервером БД) имеет ряд своих преимуществ, как-то: поддержание целостности данных при доступе многих пользователей одновременно, использование прав и ролей для разных пользователей и т.п. Но что касаемо скорости работы сервера БД — он в любом случае, по крайней мере в теории, проигрывает директивному доступу к данным. К примеру, если выдрать из того же MySQL алгоритмы доступа к данным и прикрутить их в свою программу директивно, то скорость работы существенно повысится.
Что же касается мультипользовательского(мультипроцессового) доступа к данным в директивном режиме, то это обычно тоже решаемо.
A>>>З.Ы. Товарищ DSD в свете скорого выхода новой версии SQL сервера Yukon, ваши доводы о скорости файловой системы оказываются безосновательными. DSD>>Во-первых, что такое Yukon? Во-вторых, не в файловой системе ли он хранит свои данные? A>Сюда. У него своя файловая система, заточенная для хранения реляционных данных (на самом деле это даже файловой системой в обычном понимании не является).
Это тоже не столь важно. К примеру, в InterBase тоже есть своя файловая система для своих же данных. И физически она обычно располагается в обычном файле базы данных.
Я говорил о том, сколько ресурсов обычно тратится на обеспечение режима клиент-сервер со всеми его правилами, правами доступа и т.п., а не о ресурсах, необходимых на саму выборку данных.
Здравствуйте, Andir, Вы писали:
A>Здравствуйте, DSD, Вы писали:
DSD>>И еще, Вы постите эту функцию(file_get_contents), совершенно не понимая, как она внутри работает. Единственное, чем Вы аргументируете, это то, что она "системная, и потому быстрее". То есть Вы можете выиграть спор только в тех случаях, где действительно это играет роль. В остальных случаях Вы даже обьяснить не сможете, почему быстрее работает тот или иной код.
A>Товарищ DSD сомневаться в профессиональных качествах кого-либо на данном форуме запрещено правилами!!!
А я и не сомневаюсь. Я говорю только очевидное.
И обижать я никого не собираюсь. Всего-лишь пытаюсь указать, в какую сторону, по моему мнению, человеку стоит обратить свое внимание.
В свое время я писал на перле приложение, с которым предполагалась одновременная работа нескольких сотен пользователей.
И когда у меня начал тихо виснуть сервер при около 70 онлайн-юзерах, вот тогда-то я и начал задумываться о том, что неплохо
бы узнать, что внутри делает та или иная системная функция. А до этого случая, при разработке слабонагруженных скриптов, мне тоже было все равно, как работать с файлом, в текстовом или бинарном режиме. И тоже было все равно, какие функции использовать для определенного действия, если вставал выбор из двух и более способов это действие выполнить.
A>Уважайте своих оппонентов.
A>Удачи, Andir!
)?
