Здравствуйте! Подскажите как лучше хранить данные, в mySql или в файлах? Имею ввиду в каком случае будет доступ к информации быстрее? Ну и может влияет на надежность, безопасность?
Данные в любом случае хранятся в файлах. Если вы используете базу данных, лучше и быстрее доступ к информации, плюс сервер БД (если он есть) сам старается следить за блокировками, многопоточностью, кешированием и т.п.
Плюс берет на себя логику выборок, подготовку запросов, маршрутов, хаки-фигаки и прочее. --- Добавлено --- Я так понимаю, твой вопрос можно перефразировать так: "Я никогда не пользовался БД и мне нужно мнение со стороны, стоит ли учиться этому?". Ответ - разумеется, стоит. Когда что-то сложнее хелловорлда начнешь делать, поймешь.
Нет, пользуюсь БД, но зачем-то подумал и решил, что информация в конечном итоге хранится в файлах. Дак зачем мне тогда БД, пусть создается файл, в каждую строку записывается информация, соответствующая столбцам в mySql. Затем обращаюсь к файлу и читаю строки. Так же быстрее будет, чем через mySQL! --- Добавлено --- Существует ли какое нибудь ПО, в котором можно выполнять код php построчно или по частям (либо до точки с запятой, либо по циклам...) и на каждую часть/цикл выводилось бы время исполнения (смотря в чем там измеряется)??
Человек, который пользуется БД, и который знает ее, не задает такие вопросы. Такие вопросы задает человек, знающий только про "select * from table". На этом вот моменте, собственно, между сервером БД и самописным хранилищем на файликах начинается ПРОПАСТЬ. --- Добавлено --- А у тебя сейчас есть проблемы со скоростью из-за БД? Если нет, то не решай проблемы, которых нет. И да, быстрее не будет. За исключением, конечно "select * from table". Все, что сложнее этого, даже банальный WHERE, уже ты вряд ли на PHP реализуешь быстрее, чем оно работает в MySQL. А самое смешное, что усложняя свое файлохранилище, пытаясь прикрутить сортировки, декартовы пересечения, условные выборки, ты, в итоге, напишешь свой сервер БД, но он априори будет медленнее и беднее на функционал, чем любая настоящая БД.
Не понял вопроса. Такты процессора считать? Можно замерить время обработки запроса, если именно вот время нужно.
Допустим написал код: $i = 1; $i = $i + 1; Измерил - операции выполнились за сек. Пишу таким образом код: $i = 1+1; Измерил - получил время выполнения операции 1,5 сек. И с обращениями к БД тоже измерялось бы.
Ну дык, классика же: PHP: $start = microtime(true); //начало измерения usleep(500); // какие-то действия $end = microtime(true); //конец измерения echo "Время выполнения скрипта: ".($end - $start); //вывод результата
Ну все, теперь свой код по строчкам переберу.) --- Добавлено --- И сравню как работает с БД и при хранении в файлах.
@Атм_Евгений да ну тебя с твоей скоростью. Ты нормальный тест не напишешь с таким опытом. Как сказал @Fell-x27 при полной выборке будет заведомо быстрее. Но как только что-то сложное надо будет сделать, здесь уже под вопросом. Хотя бывает, что решение на php быстрее работает, бывает наоборот - БД быстрее работает. Но чтоб реализовать без БД маломальски сложный запрос, хотя бы Код (Text): select a.id, b.name, c.cost from a join b on b.a_id = a.id join c on c.id=b.c_id where c.price < 769 тебе может потребоваться написать весьма много кода. А если в БД правильно заданы индексы, то она это сделает быстро. А самое главное, в твоём коде будет раз в 10 меньше строчек посвящено этой операции.
Вместо решения несуществующих проблем лучше тратить свое время на обучение чему-то новому. И попробовать сделать что-то сложное, в том числе с использованием БД. И научись не решать проблемы, которых нет. Как пример - я в соседней ветке уже выкладывал запросец из разряда "упоротых". С ветвящейся логикой от элемента к эелементу. Ты что-то такое на обычном файлохранилище задолбаешься реализовывать. Тяжелый ли это запрос? Тяжелый. Можно ли его переписать иначе? Скорее всего. Можно ли оптимизировать? Скорее всего. Буду ли я это делать? Нет, конечно. Этот запрос подразумевается к выполнению раз в сутки. В "технологическом окне", так называемом. Человекочасы, потраченные на переписывание себя тупо не окупят. Нужно быть прагматиком. Также не окупят себя человекочасы, потраченные на написание файлового хранилища, умеющего хотя бы десятую часть того, что умеет БД. Если углубиться в историю баз данных, окажется, что они тоже начинались с текстовых файликов обычных, где данные были записаны в определенной структуре. Сколько лет назад появились первые БД? Вот примерно на столько лет вы уже отстали со своими идеями "заведомо более быстрого решения". Если бы все было так, как вы говорите, то никто бы и не пользовался базами. Вот вам простой пример - таблица с миллионом записей. Пусть это будут логины и прочие данные пользователей. Задача элементарнейшная - по логину найти какие-то данные. Как будете реализовывать? Перед тем, как начнете придумывать циклы и сравнения по полю, вот вам инфа для размышления - при наличии индекса серверу БД понадобится, в худшем случае, всего 20 итераций, чтобы найти в миллионе записей одну нужную. При переборе циклом понадобится, в худшем случае, миллион итераций. При этом количество перебираемых данных будет несоизмеримо разным. Как и расходы памяти, соответственно. А ведь это простенький WHERE. --- Добавлено --- Скажем так, проблемы скорости БД надо решать тогда, когда они возникнут. И я гарантирую, что они возникнут гораздо позже, чем на файловом самописе. Одно дело ковырять текстовые файлики, внося так или иначе фрагментацию данных, напарываясь на рапиды, другое дело файлы БД, представляющие из себя, по факту, виртуальную файловую систему... Там все гораздо сложнее, чем кажется. И вот когда упретесь в скорость БД, то есть, по факту в производительность дисковой подсистемы. окажется, что единственное решение этой проблемы - это меморишардеры, живущие в оперативке, в памяти, которая по определению более быстрая, но энергозависимая... Но это будет ой как не скоро. А то и вовсе не будет. Это совсем другая лига и весовая категория проектов уже.