MySQL vs. .txt

[hanslinger]

Разумное замечание!

Хе. Это, между прочим, была цитата из статьи, после прочтения которой некоторые начали кричать. И привел я эту цитату не для того, чтобы показать, что "файлы рулез форева". А к сообщению:

гы-гы, БД - это же тоже файл(ы) + некоторые методы взаимодействия с данными. Так что все это реализуется в файлах

А что, от этого будет кому-то хуже?

Ага. Тем несведущим, которые пойдут по твоему пути.

Даже у MySQL есть свои реальные пределы на объем информации в веб-программировании.

А у файлов предел стремится к бесконечности, ага.

[Alexey333]

hanslinger:
Хе. Это, между прочим, была цитата из статьи

Я это знаю, так как читал эту горе-статью.

hanslinger:
Ага. Тем несведущим, которые пойдут по твоему пути.

И чем же им будет плохо? Удобство, высокая скорость работы и т.д. это плюсы.

hanslinger:
А у файлов предел стремится к бесконечности, ага.

А почему бы и нет? Такое теоретически возможно. А вот MySQL имеет свои пределы и их никак не обойдешь.

[hanslinger]

А вот MySQL имеет свои пределы и их никак не обойдешь.

Я думаю, что в ближайшем будущем мне хватит

8 миллионов терабайтов (2 ^ 63 bytes)

на таблицу...

[Alexey333]

hanslinger:
Я думаю, что в ближайшем будущем мне хватит

8 миллионов терабайтов (2 ^ 63 bytes)

на таблицу...

Ты соседние сообщения читаешь???
MySQL и при 2Гб либо загнется, либо будет очень медленно работать. Вот о каких ограничениях я говорю! Я же не говорю о том, сколько данных можно туда заложить!

[hanslinger]

Это она, может быть, сейчас загнется. А может быть, завтра выпустят патч, грубо говоря, который позволит за 0.5 миллисекунд сделать апдейты 100.000.000 записей в терабайтной базе? А патч для файлов выпустят вряд ли. Это я к тому, что дальше уже с файлами не прыгнешь.

[Alexey333]

Ну жди...

[2NetFly]

Alexey333, у тебя в гостевой книге записей на 2ГБ, или как? Ты вообще можешь просто представить себе задачу, в которой необходимо хранить количество данных такого объема?

После прочтения этой дискуссий у меня складывается такое впечатление, что в твоем понимании запрос - это максимум: SELECT field1, filed2, ..., fieldn FROM table ORDER BY field LIMIT n. А ты там о выборках из нескольких таблиц, джоинах, группировках, вложенных запросах слышал что-нибудь?

Если ты такой фанат файлов (кстати, а таблицы баз данных - это не файлы, да?), ознакомился бы с тем, что люди сделали до тебя. Тебе уже три раза про DBM сказали, слышал о такой шутке?

[2NetFly]

ето уже упоминали  но ему все равно - слово \'database\' он не приемлет по идеологическим соображениям, не важно реляционная она или нет.

В таком случае, я не буду говорить, что его текстовые файлы являются одноуровневой базой данных. А то еще не переживет, бедняжка ;=)

[Макс]

Green Kakadu:
правда Alexey333 не стоит радоваться, это не подтверждает твою теорию, что файлы рулез форевер, а лишь говорит о том, что прямые руки + знания это круто, и для реализации довольно специфичных идей +для высокой произ-ти стоит отказываться от СУБД но это делается не на ПХП

это лишь означает, что инструмент выбирается под задачу. Не более

Alexey333:
Аналогично везде можно написать функции,

только писать и отлаживать эти функции прийдется ТЕБЕ. А пользователи СУБД используют все готовое

Alexey333:
"Думаю мускл с таблицей в 2Г помрёт"

А ты сможешь обеспечить приемлемую скорость работы с фалами в 2 Гб ?
Говорить о размерах таблица не зная ее типа, струкутры и производимых запросов - глупо.
Насчет размера. Цитата из мануала :

InnoDB is used in production at numerous large database sites requiring high performance. The famous Internet news site Slashdot.org runs on InnoDB. Mytrix, Inc. stores over 1TB of data in InnoDB, and another site handles an average load of 800 inserts/updates per second in InnoDB.

(innodb - это тип таблиц в mysql)
2 ГБ информации - это много в любой СУБД (и даже для файлов) и надо применять какие-то виды оптимизации. Если у кого-то тормоза при таком объеме, значит он не нашел, как оптимизировать ее

[Alexey333]

2NetFly:
Alexey333, у тебя в гостевой книге записей на 2ГБ, или как? Ты вообще можешь просто представить себе задачу, в которой необходимо хранить количество данных такого объема?

Не знаю. Моя цель - сделать файлы удобным и быстрым способом хранения информации, независимо от объемов.

2NetFly:
Если ты такой фанат файлов (кстати, а таблицы баз данных - это не файлы, да?), ознакомился бы с тем, что люди сделали до тебя. Тебе уже три раза про DBM сказали, слышал о такой шутке?

Слышал мельком, но внимательно не читал. DBM поддерживает любой хостинг?
http://www.kurepin.ru/php/zametki/dbm/

"Операторов для работы с Berkeley DB совсем не много. Я даже не поленюсь перечислить их:

dbmopen — открыть базу
dbmclose — закрыть базу

dbmexists — проверить запись на существование
dbmfetch — получить запись
dbmreplace — заменить запись
dbminsert — вставить новую запись
dbmdelete — удалить запись

dbmfirstkey — первая запись
dbmnextkey — следующая запись"

[Макс]

Кстати, MySQL - это не самая качественная СУБД и если тормозит она, не повод отказываться от СУБД вообще.
Есть другие приемлемые альтернативы - PostgreSQL, FireBird

[Макс]

Alexey333:
DBM поддерживает любой хостинг?

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

[Alexey333]

Макс:
только писать и отлаживать эти функции прийдется ТЕБЕ.

Ну и что? Один раз написал, а потом пользуйся готовым. MySQL же тоже кто-то написал, а не ныл.

Макс:
А ты сможешь обеспечить приемлемую скорость работы с фалами в 2 Гб ?

Обеспечить хранение 2 Гб в файлах с приемлемой скоростью  смогу.

[Alexey333]

Макс:
Вот действительная причина, почему ты боишься перейти на СУБД.
Их не все хостеры поддерживают.

Нет, дело не в этом. Дело в ограниченности готовых баз данных. Нет простора для творчества.

[Макс]

Alexey333:
Дело в ограниченности готовых баз данных.

Ты не можешь судить об огрниченности СУБД.
1. ты не написал ни одного скрипт с использованием СУБД
2. ты не знаешь теории СУБД