Forum Webscript.Ru
Разное => Флейм => Тема начата: JS от 27 Октября 2004, 07:59:10
-
Народ!
Может это вопрос глупый, но мне все же интересно насколько MySQL лучше, чем обычные файлы. В частности в скорости обработки БД текста.
-
JS
[off]Боюсь этот вопрос поднимет очередную бурю в стакане, которую Ромик прихлопнет. Посмотри поиск по форуму, не ты первый[/off]
-
да
-
вообще, объяснять преимущества базы человеку, которыйникода не работал с текстовыми файлами - бессмысленно.
все равно не поймет.
Это все равно, что объяснять преимущества пхп клиенту, который ни разу не сделал ни одного сайта на статике.
-
А если вспомнить, что вопрос сей задается человеком, который пишет ПОИСКОВИК...
То хочется заплакать.
-
JS:
насколько MySQL лучше, чем обычные файлы.
это как сравнивать лопату с экскаватором.
-
Вы уж извините, но, я думаю, обсуждать в данном случае нужно не меня, а мой вопрос (я всегда думал, что именно для этого существует форум, возможно, я ошибся).
RomikChef:
вообще, объяснять преимущества базы человеку, которыйникода не работал с текстовыми файлами - бессмысленно.
все равно не поймет.
С чего вы взяли, что я никогда не работал стекстовыми файлами. Я с ними очень даже много работал, а вот MySQL - никогда. Кстати поисковик я уже сделал, но именно с стекстовыми файлами, который вы сможете увидеть в интернете в близжайшее время. И мне интересно: стоит ли переделывать под MySQL, чтобы повысить скорость обработки данных?
-
НЕТ, НЕ СТОИТ!
НИ В КОЕМ СЛУЧАЕ!!!
Если ты сделаешь на базе, то никто на него и взглянуть не придет - очередная убогая поделка.
а вот если это будет ПОИСКОВИК НА ТЕКСТОВЫХ ФАЙЛАХ, то сайту обеспечена бесплатная бешеная раскрутка! Десятки тысяч посетителей! [off]пришедших взглянуть на такого смешного уродца[/off]
Аработать не будет все равно ни тот ни другой, поэтому с этой точки зрения - без разницы
-
Что же ты и свое сообщение не удалил?
-
RomikChef:
пришедших взглянуть на такого смешного уродца
вопрос спорный. если прально организовать то вполне нормальная система может быть для небольших сайтов (см. RiSearch правда на перле)
+ не обязательно использовать SQL базу, можно и Berkeley помучать. И кстати по произ-ти она может поспорить с системой на SQL. Но это все при наличии знаний и НЕкорявых рук.
-
при чем
здесь
САЙТ?
-
JS:
Что же ты и свое сообщение не удалил?
потому, что в нем нет персональных наездов.
а есть констатация факта
-
RomikChef:
при чем
здесь
САЙТ?
Эээ, а он где искать собирается?
Я думал это скрипт поиска по сайту.
-
Да, он утверждает, что напаисал собственный яндекс.
Впрочем, пока я от комментариев воздержусь, пока не попаду на его сайт, и не посмотрю, что он там и как собрался индексировать.
Про то, что человек берется делать сайт по языку, на котором не может написать две строки самостоятельно - я уже молчу.
-
[off]Офф[/off]
О! А я его и не заметил! Сайт из серии "я возбуждён и огорчён" :)
Подписаться чтоль, на рассылку.. :))
-
RomikChef:
Про то, что человек берется делать сайт по языку, на котором не может написать две строки самостоятельно - я уже молчу.
:) а зато может мысли хорошие и в больших кол-вах роятся..
-
МЫСЛЕЙ там как раз НОЛЬ.
одни желания.
-
JS:
Народ!
Может это вопрос глупый, но мне все же интересно насколько MySQL лучше, чем обычные файлы. В частности в скорости обработки БД текста.
Вопрос вовсе не глупый.
Работу с файлами можно так организовать, что скрипт будет работать ничуть не медленнее чем с MySQL даже при огромных объемах информации. При этом работа с файлами отличается немалым удобством.
-
RomikChef
Ромик, ну раз все равно говорим -
ты-то сам чем пользуешься?
[off]Я - txt. Мне переносимость нравится. Но если убедить работать с mysql - я не против. Только аргументы пжаллста.[/off]
-
хе хе.
на овца и зверь бежит. Как будто специально тему подняли :-)
http://www.phpfaq.ru/mysql
-
RomikChef:
хе хе.
на овца и зверь бежит. Как будто специально тему подняли :-)
http://www.phpfaq.ru/mysql
Прочитал. Многие моменты вообще не соответствуют действительности.
Вот, например:
"Следующее, чем отличается БД от файла - это произвольный доступ. В файле, для того, чтобы обратиться к строке в середине, надо перебрать по очереди все идущие до неё."
Полнейшая ерунда. Так делают только начинающие (я когда только начинал тоже так делал). При работе с файлами можно легко обращаться к любой строке и элементу, независимо от его расположения.
"Если бы мы выбирали из текстового файла – нам бы пришлось написать программу не на один лист. А тут – одна строчка!"
Очередная глупость. Выборка и сортировка при работе с текстовыми файлами осуществляется ОДНОЙ СТРОКОЙ (ну или 2-3 максимум)! При этом сложноть может быть практически любая!
-
RomikChef
Можно вопрос:
почему тебя больше нет в списках форумаз на phpclub, и почему, тебя там нынче совсем не видно?
Так, из чистого любопытства.
-
ути муси-пуси :-)
ты в своей работе с файлами продвинулся до файлов с фиксированной длиной строк? Мои аплодисменты!
А индексы не изобрел еще?
-
Макар
мне самому это интересно :-)
-
RomikChef:
ути муси-пуси :-)
ты в своей работе с файлами продвинулся до файлов с фиксированной длиной строк? Мои аплодисменты!
А индексы не изобрел еще?
Я жду твоих реальных аргументов. Если их нет, то попрошу серьезно подкорректировать твою статью, так как там вранье.
-
RomikChef
нельзя сказать, чтоб я не догадывался, что ты так ответишь...
нет. а серьёзно. Что заставило тебя поменять phpclub на webscript?
-
Alexey333
А я тебя попрошу пройти на хутор бабочек ловить.
Еще не хватало, чтобы каждый хрен с горы мне тексты правил.
-
Макар
ничего я не менял. я вообще противник обменов.
почему ника RomikChef нет в списках пхпклуба - для меня загадка, ответа на которую я не знаю.
-
RomikChef:
А я тебя попрошу пройти на хутор бабочек ловить.
Еще не хватало, чтобы каждый хрен с горы мне тексты правил.
Ну тогда ты дезинформатор, который не может ответить за свои слова.
-
сколько угодно.
хоть джек-потрошитель.
меня совершенно не интересует мнение всяких ламеров.
Я иногда снисхожу до вас, чтобы ткнуть носом. Однако доказывать вам что-то - много чести. Да и бесполезная трата времени.
Вырастешь - сам поймешь. А не поймешь - тем более зачем время тратить.
-
Alexey333:
При этом работа с файлами отличается немалым удобством.
каким?
если информация будет размещаться не в одном файле, а нескольких (индексы или еще чего-то) - там ты найдешь оч.много удобства :) все-таки когда пишешь гостевую книгу можно и без БД обойтись, если что-то серьезнее, то не стоит извращаться..
[OFF]а некоторые извращенцы программируют в блокноте...[/OFF]
-
Однако, снизойду.
Alexey333:
Выборка и сортировка при работе с текстовыми файлами осуществляется ОДНОЙ СТРОКОЙ (ну или 2-3 максимум)!
у тебя только операции по открытию, закрытию и блокировке файла займут 4 строчки. Ты еще ни строчки оттуда не прочитал, ни байта не занисал, никак обрабатывать не начал. а у тебя уже 4 строчки.
а не одна-две, как ты беспомощьно пытаешься втереть окружающим.
Ты просто не понимаешь, где ты находишься. Друзьям своим-лохам впаривай эти сказки.
-
RomikChef:
сколько угодно.
хоть джек-потрошитель.
меня совершенно не интересует мнение всяких ламеров.
Я иногда снисхожу до вас, чтобы ткнуть носом. Однако доказывать вам что-то - много чести. Да и бесполезная трата времени.
Вырастешь - сам поймешь. А не поймешь - тем более зачем время тратить.
Ты слишком гордый! А гордые, как известно, больнее всего падают.
Не хочу в ответ тебя оскорблять и что-то доказывать, так как ты просто наплюешь на мои слова да и все. Да и вообще не собираюсь заниматься оскорблениями. Моя совесть будет чиста, а ты о своей позаботься.
А обо мне думай что хочешь. Меня твое мнение абсолютно не интересует. Просто ты начал откровенно дезинформировать народ, и я был обязан выступить на стороне справедливости.
-
RomikChef:
на овца и зверь бежит. Как будто специально тему подняли :-) http://www.phpfaq.ru/mysql
RomikChef, если честно статья смотрится слегка по-ламерски. С одной стороны, понятно, что написана для людей которые "не в теме" но стоит ли опускаться до уровня детского сада?
Базы данных, и в частности, язык SQL, и, в частности, СУБД MySQL - гениальное изобретение человечества.
Насчет SQL спорить не буду, но MySQL это всего лишь реализация, ничего гениального там нет, она просто бесплатна и доступна. А почитав эту фразу (даже первый абзац) создается впечатление, что все БД - реляционные, и вообще есть только MySQL и она "гениальное изобретение чел-ва" :) Впрочем следущая фраза:
Это совершенно иной подход к хранению и обработке данных, чем столетиями использовавшиеся последовательные списки.
чистой воды %$# простой пример - картотека в библиотеке, как вариант распределенной БД :)
-
Green Kakadu:
каким?
если информация будет размещаться не в одном файле, а нескольких (индексы или еще чего-то) - там ты найдешь оч.много удобства все-таки когда пишешь гостевую книгу можно и без БД обойтись, если что-то серьезнее, то не стоит извращаться..
Удобства я давно нашел и никогда не хранил все в одном файле.
Вот некоторые преимущества файлов:
1. Как тут верно заметили, это хорошая переносимость. Без труда можно перенести с одного хостинга на другой. С MySQL приходится извращаться.
2. Потенциально более высокие возможности выборки данных.
3. Потенциально более высокая скорость работы.
4. При необходимости легко подредактировать данные через обычное открытие файла.
5. Меньше требований к хостингу.
Вот некоторые навскидку.
-
RomikChef:
у тебя только операции по открытию, закрытию и блокировке файла займут 4 строчки. Ты еще ни строчки оттуда не прочитал, ни байта не занисал, никак обрабатывать не начал. а у тебя уже 4 строчки.
а не одна-две, как ты беспомощьно пытаешься втереть окружающим.
Ты просто не понимаешь, где ты находишься. Друзьям своим-лохам впаривай эти сказки.
Ну ты и артист. Я тебе говорил непосредственно о сортировке/выборке, а не считывании данных. Ведь ты же тоже не сразу все сортируешь, а подключаешься к БД, выбираешь таблицы, столбцы и т.д., т.е. тоже не одна строка!
-
Alexey333
Покажи мне пожалуйста код который будет выводить из текстового файла все записи за определённый период времени с сортировкой по нескольким полям.
Не то чтобы я тут пытаюсь кому-то доказать что текстовый файл лучше чем БД, что само по себе глупость,
просто интересно посмотреть на "2-3" строчки кода.
-
Alexey333:
Покажи мне пожалуйста код который будет выводить из текстового файла все записи за определённый период времени с сортировкой по нескольким полям.
array_filter()
array_multisort ()
-
Alexey333
сермяжная правда этой жизни состоит в том, что ничего из перечисленного мне делать не надо.
подключаюсь к бд я один раз на весь скрипт. это ОДНА строчка.
на весь скрипт. а у тебя - ЧЕТЫРЕ. на КАЖДЫЙ файл или на КАЖДУЮ операцию.
остальное - детский лепет.
да, я указываю таблицу.
прямо в запросе. в той же строчке.
да, я указываю столбцы.
ЧТОБЫ НЕ ТЯГАТЬ ЛИШНЮЮ ИНФУ, как это делаешь ты в своей песочнице с файлами. Могу и не указывать.
-
Alexey333:
1. Как тут верно заметили, это хорошая переносимость. Без труда можно перенести с одного хостинга на другой. С MySQL приходится извращаться.
mysqldump
аргумент аховый
Alexey333:
2. Потенциально более высокие возможности выборки данных.
причем объем кода при этом будет расти еще выше этих воз-тей.
Может стоит освоить SQL?
Alexey333:
3. Потенциально более высокая скорость работы.
эээ тут вопрос объемов. Если ты будешь писать свою программу на C/C++ то не спорю :) при наличии прямых рук возможно так и будет.
А скриптик на пхп :) с "более высокими возможностями выборками данных" умрет при простых операциях работы с файлом в 500+Мb
Alexey333:
4. При необходимости легко подредактировать данные через обычное открытие файла.
ню-ню, подредактируй файлик, вес которого несколько гигов
Alexey333:
5. Меньше требований к хостингу.
ты ориентируешься на скрипт для домашней странички? Да спору нет, наКуй там эти SQL да и пхп по большому счету тоже не нужен.
-
Alexey333:
array_filter()
это шутка?
-
Alexey333
Молодец :)) Ты вникни в суть вопроса. И посчитай ещё раз количество строк. раз мы уж до этого упали.
А изменение/удаление этих записей ты как сделаешь?
Я забыл уточнить что у тебя в "БД" более 10,000 записей.
-
RomikChef:
да, я указываю таблицу.
прямо в запросе. в той же строчке.
да, я указываю столбцы.
ЧТОБЫ НЕ ТЯГАТЬ ЛИШНЮЮ ИНФУ, как это делаешь ты в своей песочнице с файлами. Могу и не указывать.
Суть одна и та же.
А лишнюю инфу я тоже не читаю.
Green Kakadu:
А скриптик на пхп с "более высокими возможностями выборками данных" умрет при простых операциях работы с файлом в 500+Мb
Какие еще 500 Мб? Да при таких объемах и MySQL умрет.
Сортировка всех данных с файлами будет маловероятна, но можно сортировать часть. А вот вывод данных даже с такими объемами будет работать нормально!
Кстати, Котеров в своей книге написал, что MySQL предназначена для баз не более 100 Мб!
Green Kakadu:
ню-ню, подредактируй файлик, вес которого несколько гигов
Такого не бывает. Это ты загнул. MySQL в гигах тоже не бывает.
Green Kakadu:
ты ориентируешься на скрипт для домашней странички? Да спору нет, наКуй там эти SQL да и пхп по большому счету тоже не нужен.
Я читал, что на некоторых хостингах MySQL работает очень медленно. Видимо из-за перегрузки.
RomikChef:
это шутка?
А в чем проблема то?
-
Neter:
Молодец ) Ты вникни в суть вопроса. И посчитай ещё раз количество строк. раз мы уж до этого упали.
А изменение/удаление этих записей ты как сделаешь?
Я забыл уточнить что у тебя в "БД" более 10,000 записей.
Я уже тестировал. Сортировка 8 файлов в каждом из которых по 10000 элементов накидывает на моем слабом домашнем компьютере 3 секунды. Но мой комп в 10 раз медленнее современных. Вполне реально. Но больше 10000 я сортировать и не планирую. Смысл?
Изменение/удаление всех выбранных записей одновременно? Не думал об этом. А вот одну какую-то запись удалить не проблема.
-
Alexey333:
А лишнюю инфу я тоже не читаю.
брехня.
отвечать за слова будем, или как?
Alexey333:
Суть одна и та же.
НЕТ НЕ ОДНА!
Тебе на кажую операцию записи файла нужно ЧЕТЫРЕ СТРОЧКИ.
только ты, этого не всасываешь.
именно поэтому я не вступаю в беседы с ламерами вроде тебя. Это бесполезно. Тебе говоришь факт, а ты от него отмахиваешься.
Alexey333:
А в чем проблема то?
а в том, мой милый, что мы с тобой строчки считаем.
и Array_filter из одной строчки состоять не может. этой фунцией ты как в лужу воздух испортил.
дешевая отмазка.
и сам ты - дешевка.
что функцию в Array_filter указывай - что так пребирай, суть останется ОДНА:
1. код фильтрации ты пишешь САМ. НЕиз одной строчки.
2. перебирать тебе приходится ВЕСЬ файл.
Может, хватит уже клоуна изображать?
-
[OFF](садясь в первый ряд и беря в руки стакан с поп-корном)[/OFF] заклюют
-
Alexey333:
Какие еще 500 Мб? Да при таких объемах и MySQL умрет.
эээ мужик, ты что думаешь вся эта хрень создана чтоб хранить пару килобайт? Пример использования mysql http://livejournal.com
Проект (около 4 миллионов аккаунтов, 50 миллионов запросов в день) обслуживает распределенная система из более чем 90 серверов, построенная с использованием только открытого ПО:
- В качестве базы данных используется MySQL (кластер из реплицированных серверов);
подробнее тут:
http://forums.webscript.ru/showthread.php?s=&postid=115290
-
RomikChef:
брехня.
отвечать за слова будем, или как?
Я же сказал, что разные параметры в разных файлах храню. Поэтому считываю только те параметры, которые мне нужны для сортировки.
RomikChef:
НЕТ НЕ ОДНА!
Тебе на кажую операцию записи файла нужно ЧЕТЫРЕ СТРОЧКИ.
только ты, этого не всасываешь.
именно поэтому я не вступаю в беседы с ламерами вроде тебя. Это бесполезно. Тебе говоришь факт, а ты от него отмахиваешься.
Ну и что? Какие проблемы? Я же не утверждал, что файл совсем не надо читать (не из воздуха же данные берутся).
RomikChef:
и сам ты - дешевка.
Не обижаюсь. Пускай я дешевка!
RomikChef:
1. код фильтрации ты пишешь САМ. НЕиз одной строчки.
Могу и из одной написать. Могу и из 3. Ну не на несколько же листов как ты написал в статье! Согласен?
RomikChef:
2. перебирать тебе приходится ВЕСЬ файл.
Иногда и весь файл (у меня их несколько), а можно только часть. Я этого и не отрицал. Перебирать весь файл не обязательно при чтении! Ты все напутал и смешал в одну кучу! К тому же перебор подразумевается при использовании цикла, а я никакой цикл в данном случае не использую.
-
Green Kakadu:
обслуживает распределенная система из более чем 90 серверов
90 серверов! А попробовали бы они одну машину использовать!
Так что это не ответ. 90 серверов, потом с увеличением данных будет 150 серверов и т.д.
-
да.
с идиотами разговаривать бесполезно.
-
Alexey333:
Green Kakadu: ню-ню, подредактируй файлик, вес которого несколько гигов
Такого не бывает. Это ты загнул. MySQL в гигах тоже не бывает
из серии: "Папа это фантастика!"
MySQL версии 3.22 имеет предел по размеру таблиц 4 Гб. В MySQL версии 3.23, где используется новый тип таблиц, максимальный размер таблицы доведен до 8 миллионов терабайтов (2 ^ 63 bytes).
http://www.mysql.ru/docs/man/Table_size.html
одной таблицы.
-
RomikChef:
а. с идиотами разговаривать бесполезно.
зато забавно. Когда я только высунулся из гнезда еще хуже был
-
RomikChef:
да.
с идиотами разговаривать бесполезно.
Ну и не разговаривай.
В любом случае лучше быть идиотом чем злым :)
-
Alexey333:
Суть одна и та же.
А лишнюю инфу я тоже не читаю.
=) Ага..
Alexey333:
Кстати, Котеров в своей книге написал
Кто это?
Alexey333:
читал, что на некоторых хостингах MySQL работает очень медленно. Видимо из-за перегрузки.
Мальчик, ты хоть раз нормальный платный хостинг щупал?
Ты как тот заяц из мультика который гусеницам показывал как надо правильно ползать.
Alexey333:
Я уже тестировал.
Родной мой, скорость обработки текстовых файлов тебя никто не спрашивает, просто попробуй это реализовать двумя-тремя строчками.
Да, пусть я буду первым кто произнес в этой теме слово "DBF" :)
-
Green Kakadu:
одной таблицы
А при чем тут максимальный размер?
К сведению, MySQL используется не только в PHP, но и в прикладном программировании. Я же говорю, что это запредельные числа для нормальной работы в WEB.
http://www.securitylab.ru/forum/forum_posts.asp?TID=12104&PN=2&get=last
"Можно еще добавить, что MySQL не самая производительная СУБД и при работе с большими базами данных может изрядно тормозить. "
http://phpclub.ru/talk/showthread.php?postid=294933
"В итоге и меня получается таблица около 800 000 000 строк "
"хех, если ты собрался на этих записях делать сложные выборки, в режиме реального времени... лучше пойди, удавись сразу..."
-
Neter DBM?
-
NeoNox:
К сведению, MySQL используется не только в PHP, но и в прикладном программировании. Я же говорю, что это запредельные числа для нормальной работы в WEB.
ээ, я ж тебе нормальный пример дал ЖЖ.
почему тебе кажется, что БД в несколько гиг - это что-то выдающееся? Посмотри на интернет чуть выше домашних страниц :)
Alexey333:
А при чем тут максимальный размер?
ты же сам сказал, что " MySQL в гигах тоже не бывает" на что я и ответил.
Alexey333:
сведению, MySQL используется не только в PHP, но и в прикладном программировании.
спасибо за сведения :)
на сайте dev.mysql.com был опрос о популярном API при работе с бд ( http://dev.mysql.com/tech-resources/quickpolls/favourite-connector.html )
PHP (mysql/mysqli) 1987 (52.6%)
Perl (DBI) 334 (8.8%)
Connector/J (JDBC) 602 (15.9%)
в серьезных проектах mysql не очень то и используется из-за отсутствия многих функций.
-
Alexey333:
"В итоге и меня получается таблица около 800 000 000 строк "
уверен на 99,999999999999% что если ты будешь использовать в качестве БД под это просто файл и разбирать его php скриптом то ничего вообще не получится
-
Neter:
Кто это?
Автор книги "Самоучитель PHP 4". Он и в интернете бывает. http://dklab.ru/ - его сайт.
Вот что он пишет в книге:
"Одна из самых популярных СУБД, которые используются в Web-программировании, - MySQL. Она предназначена для создания небольших (сравнительно, конечно - скажем, не более 100 Мбайт) баз данных, и поддерживает подмножество языка запросов SQL."
Neter:
Мальчик, ты хоть раз нормальный платный хостинг щупал?
Так жаловались как раз купившие платный хостинг.
Neter:
Родной мой, скорость обработки текстовых файлов тебя никто не спрашивает, просто попробуй это реализовать двумя-тремя строчками.
А если будет не 3 строчки, а 5, то уже конец??? Разные задания. Часто можно и одной строчкой отсортировать.
А про скорость ты все таки намекал. Иначе зачем ты назвал число 10000, если разницы нет сколько?
-
Green Kakadu:
ты же сам сказал, что " MySQL в гигах тоже не бывает" на что я и ответил.
Так теоретически и файл такого размера может быть (это то все знают). Читал я до этого и твой приведенный отрывок. Не не бывает теоретически, а практически на сайтах.
А пример с журналом непоказателен, так как там 90 мощных серверов работают под один сайт + масса оптимизаций и фич.
Green Kakadu:
уверен на 99,999999999999% что если ты будешь использовать в качестве БД под это просто файл и разбирать его php скриптом то ничего вообще не получится
Все возможно...
-
Alexey333:
1. Как тут верно заметили, это хорошая переносимость. Без труда можно перенести с одного хостинга на другой. С MySQL приходится извращаться. 2. Потенциально более высокие возможности выборки данных. 3. Потенциально более высокая скорость работы. 4. При необходимости легко подредактировать данные через обычное открытие файла. 5. Меньше требований к хостингу.
Во-первых о хостинга.
Ни о какой профессиональной работе не может идти и речи, если ты не можешь управлять хостингом (установка нового софта или апгрейд старого).
2 и 3 - неправда (ты не знаешь SQL + не работал с большими объемами данных).
4 - этого не надо хотеть
А теперь вопрос.
Как ты сделаешь следующую (вобщем-то типичную для СУБД) задачу.
Есть список сотрудников компании (ФИО, возраст, зарплата, адресс, должность) и есть список качеств (ответсвенность, аккуратность, скурпулезность и т.д.)
У каждого сотрудника может быть свой список качеств. У кого-то их 10, у кого-то 5.
Как ты организуешь свои файлы для хранения таких данных (сотрудников и их качеств).
Операции, которые нужно будет производить :
1. Выбрать всех сотрудников у которого есть такое-то качество
2. Выбрать 5 наиболее популярных качеств
3. Вывести таблицу, в одном столбце - качество, во втором - кол-во сотрудников, имеющих это качество.
С использованием СУБД эти задачи решаеются одним SQL-запросом
-
А чего обсуждать? Залей себе на хостинг базу в 1 Гб и напиши под нее какой-нибудь скрипт, замерь скорость, а мы все проверим.
Если скорость будет приемлемая (скажем, не более 3-5 секунд), то ты оказался прав.
-
100
Alexey333:
Она предназначена для создания небольших (сравнительно, конечно - скажем, не более 100 Мбайт) баз данных
давно это было :)
Переходим с PHP на Perl, как это ни печально... (http://dklab.ru/work/php2perl.html) - мне эта статья больше всего нравится ([off]Perl rulezzZ forever![/off]).
-
Alexey333:
"Одна из самых популярных СУБД, которые используются в Web-программировании, - MySQL. Она предназначена для создания небольших (сравнительно, конечно - скажем, не более 100 Мбайт) баз данных, и поддерживает подмножество языка запросов SQL."
во-первых, это лишь мнение Котерова
во-вторых, эта книга была написана давно, с тех времен mysql сильно изменился
-
Alexey333:
Если скорость будет приемлемая (скажем, не более 3-5 секунд), то ты оказался прав
Кстати, а как ты узнаешь время отклика базы?
-
Макс:
не работал с большими объемами данных
Работал (тестировал).
Макс:
С использованием СУБД эти задачи решаеются одним SQL-запросом
Если я напишу функцию, то тоже все будет одной строчкой решаться. Надо же понимать, что вы только передаете параметры, а MySQL выполняет все эти невидимые для вас действия.
А решать тут твою задачку я не собираюсь. Зачем мне это надо? Те задачи, которые передо мной встают, я успешно решаю, а отчитываться перед каждым как школьник я не собираюсь.
Green Kakadu:
Кстати, а как ты узнаешь время отклика базы?
Понятия не имею. Ведь пишут же (например, на некоторых форумах IPB) время выполнения скрипта. Как у обычного скрипта это время посчитать я знаю, а если с MySQL что-то особенное, то ты должен знать.
Кстати, здесь же и считается:
Страница сгенерирована за 0.48648810 секунд (кстати, не так уж и быстро...)
-
Макс, принял эстафету метания бисера?
удачи тебе :-)
-
RomikChef:
Макс, принял эстафету метания бисера? удачи тебе :-)
Нет, я уже сдаюсь :-)
-
Ладно :) Удачи вам :)
Когда-нибудь вы все поймете!
-
Alexey333:
Страница сгенерирована за 0.48648810 секунд (кстати, не так уж и быстро...)
это все вместе - бд + php, причем если посмотришь выполняется ~ 20 запросов к БД.
Alexey333:
Когда-нибудь вы все поймете!
наверное нет, это глухой тупик
-
Судя по всему пора исключать MySQL из обязательной программы изучения РНР, а то люди начинают думать, что кроме как
select * from mytable order by my_field MySQL ничего не умеет и начинают сравнивать его с текстовыми файлами.
-
Green Kakadu:
это все вместе - бд + php, причем если посмотришь выполняется ~ 20 запросов к БД.
Не надоело? Ну не всасывает чувак, КАКОЙ объем информации обрабатывается за эти пол-секунды.
Ну не объяснишь ты слепому, что такое синий цвет.
-
RomikChef:
Ну не объяснишь ты слепому, что такое синий цвет.
я слышал некоторые слепые различают цвет на ощупь (там аура какая-то или еще что-то)
-
Green Kakadu:
это все вместе - бд + php, причем если посмотришь выполняется ~ 20 запросов к БД.
От этого не легче.
Green Kakadu:
наверное нет, это глухой тупик
Топик тут ни при чем. Здесь никто никому уже ничего не докажет. Жизнь покажет и дальнейшее развитие событий.
RomikChef:
Не надоело? Ну не всасывает чувак, КАКОЙ объем информации обрабатывается за эти пол-секунды.
Ну не объяснишь ты слепому, что такое синий цвет.
В любом случае это НЕ БЫСТРО. Причем скорость может меняться. Вот сейчас, например, пишет "Страница сгенерирована за 0.98747706 секунд ". Почти секунда! С файлами все происходит гораздо быстрее.
И не надо говорить, что я что-то не вижу. Полсекунды, секунда...все ясно написано. А если объем форума увеличится в 10 раз, то можно предположить, что по 5-10 секунд будет загружаться (хотя не знаю насколько верно такое предположение).
Green Kakadu:
я слышал некоторые слепые различают цвет на ощупь (там аура какая-то или еще что-то)
Я вообще все прочитал и сюда скопировал. Скорость работы ясно написана.
Понимаю, что вы скажете "Ну и что что медленно, зато это MySQL, это круто! Ты не видишь очевидного!" и т.п. Я вижу факты.
Еще раз предлагаю: продемонстрируйте скорость скрипта с размером базы в 1 Гб (на одной машине без особыч оптимизаций и фич). Если скорость будет приемлемая, то я с вами соглашусь!
-
Понимаю, что вы скажете "Ну и что что медленно, зато это MySQL, это круто! Ты не видишь очевидного
кстати, это очень точно показывает проблему.
для него аргументы сводятся только к таким. Только такие он и может понять.
Alexey333:
Если скорость будет приемлемая, то я с вами соглашусь!
Задай себе вопрос.
Кому ты нужен - что-то тебе доказывать?
-
RomikChef:
кстати, это очень точно показывает проблему.
для него аргументы сводятся только к таким. Только такие он и может понять.
Просто теоретически все мастера рассуждать, но когда доходит до практики, то тут уже все не кажется таким безоблачным.
Ведь не зря же создатели онлайн журнала подключили к одному сайту с MySQL 90 серверов и все максимально оптимизировали. Люди реально смотрят на вещи и понимают, что просто так проблему больших объемов не решишь. А тут кого ни послушаешь, так MySQL волшебным образом с любыми объемами без труда справится и работать предельно просто и т.п. фантастика.
Я видел скрипты с MySQL, и они далеко не из одной строчки состоят. Последние версии VB весят как минимум несколько Мб. Вот и посчитайте сколько там строчек.
RomikChef:
Задай себе вопрос.
Кому ты нужен - что-то тебе доказывать?
Ну, конечно, гораздо проще наплевать на чужое мнение и твердить свое при этом взахлеб оскорбляя. Для этого большого ума не надо. Написал какую-то лажу в статье и впаривай ее окружающим, а кто не согласен, тому можно плюнуть в лицо. Вот и вся твоя теория. Вот только подумай, что твоя статья держится только на твоем личном слове. А вот если бы она подкреплялась конкретными тестами и примерами, то ее цена была бы намного выше! Ведь тесты это уже не теория, а конкретные реальные факты.
-
Alexey333:
Ну, конечно, гораздо проще наплевать на чужое мнение
на мнение наплеваь сложно. Если оно есть.
Если же есть сопли безмозглого ламера, то на них - действтительно - можно тоьлко положить.
Alexey333:
вот если бы она подкреплялась конкретными тестами
повторяю. для особо одаренных.
Те, кого статья не убеждает, могут ей не пользоваться вовсе.
Я не проповедник. Никого в свою религию не затаскиваю. Мое дело - ответить на часто задаваемые вопросы. И уговаривать каждого безмозглого болвана в мои планы не входит.
Но ты даже эту простую мысль понять не в состоянии.
-
Alexey333 а трудно в гугле набрать mysql vs flat files, прочитать сотню страниц и сделать выводы? а если есть время, написать простой скрипт активно использующий файлы и такойже но с бд, запустить к примеру ab и посмотреть результаты?
-
Alexey333
твоя пробюлема в том, что ты не пытаешься разобраться, почему все используют SQL-базы. Ты в них прежде всего ищешь недостатки и не обращаешь внимание на достонства.
-
RomikChef
Не хочу с тобой больше разговаривать. Ты для меня не авторитет и никогда им не был.
Скоро я напишу свои статьи и буду распространять их по интернету. Хватит уже этого беспредела.
NeoNox:
Alexey333 а трудно в гугле набрать mysql vs flat files, прочитать сотню страниц и сделать выводы? а если есть время, написать простой скрипт активно использующий файлы и такойже но с бд, запустить к примеру ab и посмотреть результаты?
Я уже смотрел что пишут. В принципе ничего существенного.
Что касается скрипта, то я их написал уже немало, но все они используют файлы. Проводил также много тестов на скорость и имею насчет данного вопроса конкретное представление. А вот с MySQL не написал ни одного скрипта. Поэтому провести такое сравнение не могу.
-
Макс:
твоя пробюлема в том, что ты не пытаешься разобраться, почему все используют SQL-базы. Ты в них прежде всего ищешь недостатки и не обращаешь внимание на достонства.
Тоже самое можно сказать и о файлах. Кто их не любят (например, Роман), те в противовес приводят самые неоптимальные решения. Вообще в инете даже в статьях порой дают такие советы по работе с файлами, что после них пропадет всякое желание с ними работать. Например, в одной статье дается рекомендация удалять строку, перебирая циклом все элементы! Это же полнейшая глупость. Как только число элементов станет большим, то скрипт вообще перестанет нормально работать. Вот такие горе-писатели дискредитируют файлы.
Что касается удобства, то можно написать готовые функции и лишь подставлять нужные параметры. Даже думать особо не надо будет.
А достоинства у MySQL, несомненно, есть. Но там уже все конкретизировано и как-то усовершенствовать трудно. С файлами же есть большое поле для деятельности. Это гимнастика для ума и плацдарм для новых технологий.
-
Макс:
твоя пробюлема в том
Кстати, а какая у меня проблема??? Я свои задачи без проблем решаю.
-
Вах, баюс-баюс!
-
Alexey333:
Кстати, а какая у меня проблема??? Я свои задачи без проблем решаю.
спецы по СУБД более оплачиваемые, нежели специалисты по файлам :)
-
Alexey333:
Но там уже все конкретизировано и как-то усовершенствовать трудно.
ты не можешь об этом судить поскольку
1. не написал ни одного скрипта с использованием СУБД
2. не знаком с теорией СУБД (теория != мануал по mysql)
-
Alexey333:
Это гимнастика для ума и плацдарм для новых технологий.
чума
редко встретишь такого развесистого демагога
-
Alexey333:
Скоро я напишу свои статьи и буду распространять их по интернету. Хватит уже этого беспредела
ждем с нетерпеием, о великий и могучий повелитель файлов.
Alexey333:
Это гимнастика для ума и плацдарм для новых технологий.
оч.сомнительно насчет "плацдарма новых технологий"
Alexey333:
Вот такие горе-писатели дискредитируют файлы.
бедные файлы
-
RomikChef:
Вах, баюс-баюс!
Не зря, не зря :)
Макс:
спецы по СУБД более оплачиваемые, нежели специалисты по файлам
Хм, однако же ты прав. Это действительно серьезная проблема :(
-
Alexey333:
Макс:
спецы по СУБД более оплачиваемые, нежели специалисты по файлам
Хм, однако же ты прав. Это действительно серьезная проблема
ну учитывая, что файлы - плацдарм для новых технологий, ты в корне можешь изменить ситуацию, главное донести эту идею до работадателя.
-
[OFF]В наш городок заехал цирк...[/OFF]
-
Alexey333:
Скоро я напишу свои статьи и буду распространять их по интернету. Хватит уже этого беспредела
зачоот=)
-
Alexey333
Так, давай по-порядку.
Как ты считаешь, почему файлы лучше СУБД?
1. Выше скорость извлечения/добавления/изменения данных при меньшем потреблении ресурсов компьютера.
2. Запросы на извлечение/добавление/изменение строятся удобнее, проще и быстрее. Более быстрая разработка приложения использующего текстовые файлы в качестве БД.
3. Удачно реализован механизм блокировок, в т.ч. отдельных записей.
4. Более высокая надёжность хранения данных. Я люблю хранить пароли в текстовых файлах.
5. Возможность строить сложные запросы. С многочисленными объединениями, сортировками, агрегатными функциями.
6. Файл можно принести в церковь и осветить за 50 рублей/мегабайт.
7. Мне нравится как в них реализован автоинкремент, индексы и уникальные поля.
8. Я люблю хранить в них бинарные данные.
9. Поддержка целостности данных очень помогает мне.
0. Мой TXT-файл очень любит работать с транзакциями.
-
Neter:
6. Файл можно принести в церковь и осветить за 50 рублей/мегабайт.
Неудачное предложение.
-
Alexey333 а мне понравилось. только дамп базы данных тоже туда стоит принести, мало-ли что с ним при mysqldump-e случится.
-
Не хочу с вами больше разговаривать. Вы уже переходите все границы и шутите над тем, над чем нельзя шутить.
Да, и доказывать я вам больше ничего не собираюсь. Есть в жизни более важные моменты, чем ваши теории. Вы же тут ослеплены непомерной гордостью и фанатизмом, и я даже близко не хочу становиться таким. Можете продолжать называть меня идитотом. Хуже этим вы мне не сделаете (только себе).
-
поколения программистов были слепы... но тут в Интернете появляются статьи... статьи про использование файлов! и все начинают прозревать...
Alexey333
а не подскажешь ли, как в файлах хранить иерархические данные? например, реализовать Nested Sets? или начинать использование файлов совместно с папками и делать обход папок червячком при помощи файловых функций, загонять структуру папок в массивы, а потом работать с массивами?
в одном и другом файле есть какие-то данные, надо из обоих вывести только те записи, у которых сумма записей одного поля и записей другого поля из другого файла равна определенному числу. И т.д.
Возвращаемся к основам... (http://russian.joelonsoftware.com/Articles/BacktoBasics.html)
-
Yukko:
а не подскажешь ли, как в файлах хранить иерархические данные? например, реализовать Nested Sets? или начинать использование файлов совместно с папками и делать обход папок червячком при помощи файловых функций, загонять структуру папок в массивы, а потом работать с массивами?
гы-гы, БД - это же тоже файл(ы) + некоторые методы взаимодействия с данными. Так что все это реализуется в файлах :)
другое дело, что удобнее(надежнне/быстрее): все писать самому или часть работы возложить на базу?
Это я к тому, что никто не мешает в файле похранить любые данные (любые структуры данных) :) они ж там рано или поздно все равно окажутся
-
Green Kakadu, правильно, я требую продолжения банкета!:) Даёшь MySQL на пхп!!!:)
[OFF]Эх, какую хорошую тему только сейчас заметил. Пока читал - плакалЪ:) (садится рядом с NeoNox\'ом на первый ряд)[/OFF]
-
Green Kakadu это как раз самое смешное во всей истории.
чувак ваяет самопальную бд, но вслепую, и очень фанатично :-)
-
Примечание: На самом деле, БД - это не волшебный ящик, и хранит она данные не в нематериальном эфире, а в тех же самых файлах. И точно так же их переписывает. Но делает это она совершенно прозрачно для пользователя.
С чего все начиналось-то... :super:
-
видать, человек был слишком религиозен и решил отказаться от такой интересной дискуссии, обидевшись на шутку про освещение файлов за 50 рублей за мегабайт... :)
Ничего, я думаю, что у него все наладится, когда он будет делать первый заказ с СУБД :)
-
Посоветовали бы человеку про DBM почитать, а то у него, похоже, "синдром гениального изобретения".
-
2NetFly:
Посоветовали бы человеку про DBM почитать
ето уже упоминали :) но ему все равно - слово \'database\' он не приемлет по идеологическим соображениям, не важно реляционная она или нет.
-
Всем любителям файлов посвящается:
Подбор СУБД для поисковой системы (http://forum.searchengines.ru/showthread.php?postid=794772#post794772)
правда Alexey333 не стоит радоваться, это не подтверждает твою теорию, что файлы рулез форевер, а лишь говорит о том, что прямые руки + знания это круто, и для реализации довольно специфичных идей +для высокой произ-ти стоит отказываться от СУБД :) но это делается не на ПХП
еще сосулка:
inverted files construction (http://www.google.com/search?hl=ru&q=inverted+files+construction&lr=)
-
hanslinger:
Примечание: На самом деле, БД - это не волшебный ящик, и хранит она данные не в нематериальном эфире, а в тех же самых файлах. И точно так же их переписывает. Но делает это она совершенно прозрачно для пользователя.
С чего все начиналось-то...
Разумное замечание!
А то заявляется, что MySQL решает проблемы одной строкой, хотя в другом месте он же поясняет, что действия все же производятся, только невидимо для программиста. Аналогично везде можно написать функции, подставлять значения, а потом орать, что одна волшебная строка все выполняет!
Yukko:
видать, человек был слишком религиозен и решил отказаться от такой интересной дискуссии, обидевшись на шутку про освещение файлов за 50 рублей за мегабайт...
Почему был???
А от дискуссии с нормальными людьми я не отказываюсь. Почему они должны отвечать за других?
2NetFly:
а то у него, похоже, "синдром гениального изобретения".
А что, от этого будет кому-то хуже?
Green Kakadu:
ето уже упоминали но ему все равно - слово \'database\' он не приемлет по идеологическим соображениям, не важно реляционная она или нет.
Упоминали, но ссылку не дали.
А к слову "database" я нормально отношусь! Здесь важен сам принцип.
Green Kakadu:
Всем любителям файлов посвящается:
Подбор СУБД для поисковой системы
Я там приметил сообщения на тему нашего немного прошлого обсуждения:
"Думаю мускл с таблицей в 2Г помрёт"
"Не помрет, но будет долго ломаться. Пробовала. Результат неутешителен. "
Теперь понял о чем я говорил? Даже у MySQL есть свои реальные пределы на объем информации в веб-программировании.
-
Разумное замечание!
Хе. Это, между прочим, была цитата из статьи, после прочтения которой некоторые начали кричать. И привел я эту цитату не для того, чтобы показать, что "файлы рулез форева". А к сообщению:
гы-гы, БД - это же тоже файл(ы) + некоторые методы взаимодействия с данными. Так что все это реализуется в файлах
А что, от этого будет кому-то хуже?
Ага. Тем несведущим, которые пойдут по твоему пути.
Даже у MySQL есть свои реальные пределы на объем информации в веб-программировании.
А у файлов предел стремится к бесконечности, ага.
-
hanslinger:
Хе. Это, между прочим, была цитата из статьи
Я это знаю, так как читал эту горе-статью.
hanslinger:
Ага. Тем несведущим, которые пойдут по твоему пути.
И чем же им будет плохо? Удобство, высокая скорость работы и т.д. это плюсы.
hanslinger:
А у файлов предел стремится к бесконечности, ага.
А почему бы и нет? Такое теоретически возможно. А вот MySQL имеет свои пределы и их никак не обойдешь.
-
А вот MySQL имеет свои пределы и их никак не обойдешь.
Я думаю, что в ближайшем будущем мне хватит
8 миллионов терабайтов (2 ^ 63 bytes)
на таблицу...
-
hanslinger:
Я думаю, что в ближайшем будущем мне хватит
8 миллионов терабайтов (2 ^ 63 bytes)
на таблицу...
Ты соседние сообщения читаешь???
MySQL и при 2Гб либо загнется, либо будет очень медленно работать. Вот о каких ограничениях я говорю! Я же не говорю о том, сколько данных можно туда заложить!
-
Это она, может быть, сейчас загнется. А может быть, завтра выпустят патч, грубо говоря, который позволит за 0.5 миллисекунд сделать апдейты 100.000.000 записей в терабайтной базе? А патч для файлов выпустят вряд ли. Это я к тому, что дальше уже с файлами не прыгнешь.
-
Ну жди...
-
Alexey333, у тебя в гостевой книге записей на 2ГБ, или как? Ты вообще можешь просто представить себе задачу, в которой необходимо хранить количество данных такого объема?
После прочтения этой дискуссий у меня складывается такое впечатление, что в твоем понимании запрос - это максимум: SELECT field1, filed2, ..., fieldn FROM table ORDER BY field LIMIT n. А ты там о выборках из нескольких таблиц, джоинах, группировках, вложенных запросах слышал что-нибудь?
Если ты такой фанат файлов (кстати, а таблицы баз данных - это не файлы, да?), ознакомился бы с тем, что люди сделали до тебя. Тебе уже три раза про DBM сказали, слышал о такой шутке?
-
ето уже упоминали но ему все равно - слово \'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 ГБ информации - это много в любой СУБД (и даже для файлов) и надо применять какие-то виды оптимизации. Если у кого-то тормоза при таком объеме, значит он не нашел, как оптимизировать ее
-
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 поддерживает любой хостинг?
Вот действительная причина, почему ты боишься перейти на СУБД.
Их не все хостеры поддерживают.
А потребовать от заказчика качественный хостинг ты не решаешься (он ведь просто уйдет к другому, такому же как ты)
-
Макс:
только писать и отлаживать эти функции прийдется ТЕБЕ.
Ну и что? Один раз написал, а потом пользуйся готовым. MySQL же тоже кто-то написал, а не ныл.
Макс:
А ты сможешь обеспечить приемлемую скорость работы с фалами в 2 Гб ?
Обеспечить хранение 2 Гб в файлах с приемлемой скоростью смогу.
-
Макс:
Вот действительная причина, почему ты боишься перейти на СУБД.
Их не все хостеры поддерживают.
Нет, дело не в этом. Дело в ограниченности готовых баз данных. Нет простора для творчества.
-
Alexey333:
Дело в ограниченности готовых баз данных.
Ты не можешь судить об огрниченности СУБД.
1. ты не написал ни одного скрипт с использованием СУБД
2. ты не знаешь теории СУБД
-
Макс:
Ты не можешь судить об огрниченности СУБД.
Приведи пример.
-
Ты не можешь судить об огрниченности СУБД.
1. ты не написал ни одного скрипт с использованием СУБД
2. ты не знаешь теории СУБД
Я бы сформулировал первый пункт немного по-другому: он просто не сталкивался с задачами, которые нельзя решить текстовыми файлами. И пока этого не произойдет, что-то объяснять нет смысла.
-
И пока этого не произойдет, что-то объяснять нет смысла.
Похоже на то +)
-
Alexey333:
Дело в ограниченности готовых баз данных.
:)))
Вот у меня вопрос возник. А какого ты пишешь на пхп?
Вот есть прекрассный язык - ассемблер называется. Сплошные плюсы, и производительновть, и возможности.
А ещё лучше машинные коды:)
-
Насчет DBM:
DBM администраторов сущ.несколько - есть различия по максимальной длине одной записи, структуре хранения записей. На любом *nix хостинге какой-нибудь DBM администратор да будет
Если говорить о BerkeleyDB (одна из самых распространенных, производительных и надежных реализаций) то вот сайт производителя:
http://sleepycat.com/
насчет кол-ва операторов для работы :) все вышеперечисленное - это лишь то, что предлагает пхп, API там помощнее будет. Поддерживаются транзакции
-
Alexey333:
Моя цель - сделать файлы удобным и быстрым способом хранения информации, независимо от объемов.
весьма благородная миссия. а чем они сейчас занимаются?
ты говоришь о создании своей системы управления базой данных, т.е. о написании некоторых методов (функций) которые позволят записывать/выбирать данные из файла(ов) :) т.е. ты пишешь свою СУБД, только на пхп и при этом пытаешься все это противопоставить системам, написанных на С/C++ :) поэтому это и забавно
-
Alexey333:
Не знаю. Моя цель - сделать файлы удобным и быстрым способом хранения информации, независимо от объемов.
ГЫГЫГЫГЫГЫ!
И вышел таки обратно на Дерибасовскую!
-
Alexey333:
Ну и что? Один раз написал, а потом пользуйся готовым. MySQL же тоже кто-то написал, а не ныл.
Только разница в том, что мускуль ипсали сотни людей не один год. А не один лох голозадый.
Alexey333:
Дело в ограниченности готовых баз данных. Нет простора для творчества.
Не тебе, чурке неграмотной, о базах судить, которых ты в глаза не видел и которыз боишься, как огня.
Как раз бд предоставляет простор для творчества - творчества обработки данных. И при этом не нужно корпеть над техниескими проблемами. Только ты, в смлу своей ментальной ограниченности, просто этот простор не всасываешь.
-
glebushka , 5 баллов.
Причем если бы у нашего уважаемого оппонента была хотя бы капля мохзгов в той части тела, которая у него служит только для приема пищи, то он бы понял этот аргумент.
Но, как здесь уже неоднократно отмечали, беседа здесь идет с идиотом, который просто не понимает того, что ему говорят.
И поддерживается она исключительно силами новых волонтеров, которые еще не въехали в тот простой факт, что наше чучело стоеросовое просто не понимает ни бельмеса, а тупо долдонит единственную песню, которая помещается в его микроскопических мозгах.
-
RomikChef:
что мускуль ипсали сотни людей не один год
ну может и не сотни - все-таки mysql лишь распространяется как open source, а разрабатывается и поддерживается силами компании Mysql AB. Другое дело, что разрабатывалось это (да все БД) высококвалифицированными программистами :) и может какой-нибудь гений-одиночка и способен наваять что-то приличное и толковое (конкурентноспособное), но Alexey333 под такое определение явно не подходит.
-
Алгоритмы, такие как сортировка или рекурсивный проход по дереву, не меняются десятками лет, но Alexey333 их не знает. Каждый раз, когда ему приходится решать проблему, которой у профессионала просто нет - он изобретает что-то свое и с упорством достойным иного применения защищает только-что созданную трехногую лошадку. И самое интересное, он будет проходить весь путь эволюции с самого начала, подтверждая поговорку - умные учатся на чужих ошибках.
-
Alexey333:
MySQL и при 2Гб либо загнется, либо будет очень медленно работать.
Дело в том, что ты не понимаешь почему это происходит.
Я тебе в этом случае подскажу: это особенности файловой системы, а ни как не технологии. В 99% случая это невозможность создать один файл размером более 2Гб. Лечится это установкой патча фс, а ни как не ожидания патча от mysql девелоперов.
-
А кто-нибудь видел хоть кусочек кода для работы с файлами от Alexey333?
-
кстати, откуда всплыл этот бред про то, что мускуль при размерах бд под два гига загнется или будет медленно работать?
-
RomikChef просто неверная формулировка.
пошукай "mysql 2Gb file problem" в гугле.
http://dev.mysql.com/doc/mysql/en/Full_table.html
-
какая разница - какая формулировка, если все это не имеет нималейшего отношения к вопросу?
-
Имеет место заблуждение в вопросе. Все остальное действительно - без разницы.
-
Alexey333:
Макс:
Ты не можешь судить об огрниченности СУБД.
Приведи пример.
Пример чего ???
-
уфф... наконец таки дочитал... :)
Макс
NeoNox
RomikChef
Croaker
Green Kakadu
glebushka
и другие...
не надо отдать должное человеку... :) столько флуда развести из пустого места, это надо уметь... :)
Alexey333
Чем то мне это напомнило сравнение Объектно-Ориентированного Программирования с процедурным...
Но это лирическое отступление... :)
В результате своих долгих и мутарных страданий над файлами ты напишешь свое подобие SQL, конечно оно будет немного отличаться... но ключивые моменты будут схожими... и ты с удивлением для себя это обнаружишь...
В этом случае ты будешь просто герой и для меня будет честь пожать тебе руку...
Но правда жизни мне подсказывает что ты рано или поздно перейдешь на SQL поняв что велосипеды изобритают только избранные...
-
To all
Давно читаю, думаю, дай тоже что-нибудь скажу...
RomikChef:
Не тебе, чурке неграмотной, о базах судить, которых ты в глаза не видел и которыз боишься, как огня.
Если убрать, некоторые колкости ;) то Ромик, просто и конкретно описал проблемуAlexey333...
На моем примере, могу сказать, что я очень долго упирался руками и ногами прежде чем начал использовать SQL. Правда, я такую демагогию не разводил, а просто молча, никого не спрашивая, юзал файлы.
Почему? ответ простой: Я БОЯЛСЯ потерять прямой доступ к данным, как можно управлять и выбирать данные, которые храняться непонятно где и непонятно как, и нотепад уже не поможет, а что бы найти одну строку нужно было сделать кучу "странных" манипуляций!
Страшно, когда можно запихнуть данные, в базу, а потом вдруг не найти куда запихнул... и как искать-то?
Я с содраганием набирал первые "инсерты", "апдейты" и "селекты"... каждый раз перепроверяя и боясь, что селал, что-то не так... страшно вспомнить... и смешно тоже...
А выдумывание какой-то своей БД на основе текстовых файлов, всего лишь оправдание невежества... увы, увы...
-
с содраганием набирал первые "инсерты", "апдейты" и "селекты"... каждый раз перепроверяя и боясь, что селал, что-то не так... страшно вспомнить... и смешно тоже...
Ага. А я еще сначала боялся сложности языка SQL. Пока его не увидел :). Но боялся жутко, поэтому использовал файлы, чаще всего неправильно.
-
commander:
Чем то мне это напомнило сравнение Объектно-Ориентированного Программирования с процедурным...
тебе мало? =) хочешь еще про это почитать? =)
hanslinger:
Ага. А я еще сначала боялся сложности языка SQL. Пока его не увидел
я до сих пор боюсь инсертов упдейтов и селектов. если они тока в stored procedure-s не упрятаны
-
AliMamed
тебе мало? =) хочешь еще про это почитать? =)
:) спасибо... начитался про это в своё время по самое не балуй... :) больше как-то не хочеться...
-
Phoinix:
Страшно, когда можно запихнуть данные, в базу, а потом вдруг не найти куда запихнул... и как искать-то?
Я с содраганием набирал первые "инсерты", "апдейты" и "селекты"... каждый раз перепроверяя и боясь, что селал, что-то не так... страшно вспомнить... и смешно тоже...
прямо ужастики Стивена Кинга :)
-
Green Kakadu
прямо ужастики Стивена Кинга
Не то слово, файл хоть копию сделать можно, а базу - надо дамп делать.
Делаешь команду UPDATE забыв (или неправильно) указав условие, и Стивен Кинг начинает отдыхать... ;)
Правда, потом привыкаешь, и не принимаешь это близко к сердцу...
-
Делаешь команду UPDATE забыв (или неправильно) указав условие, и Стивен Кинг начинает отдыхать...
Phoinix
это не самое страшное... страшно когда на финальных тестах проэкта, выясняеться, что структура таблиц была не верно спланирована... а для переделки придеться месяц всей команде работать... вот это по настоящему страшно...
-
Phoinix
забыл добавить... а ты при этом руководитель направления... :)
-
commander
страшно когда на финальных тестах проэкта, выясняеться, что структура таблиц была не верно спланирована...
Ну то же самое происходит и при хранении данных в файлах...