База данных однозначно.

Почему ? в чем разница

linker
Да, почему? Интересно...

Щас в меня полетят камни и палки, может быть меня даже распнут на логотипе этого форума, но я выбираю файлы.

Быстро, удобно и прочее. Слишком много чтобы перечислять.

А корректней их было-бы называть так http://en.wikipedia.org/wiki/Flat_file_database

А вот такой гигант как Google выбирает файлы, потому что быстрей))

Хотя считается что сравнивать не корректно, ведь внутри SQL те же файлы, а сам язык просто средство для работы с ними.

Bossmen
Так у них и на PHP вряд ли что-либо написано. Связка PHP+Database работает быстрее и удобнее, нежели PHP+File

Такой гигант как я тоже выбирает файлы, но вопрос в хорошей библиотеке для работы с данными. Что-бы было быстро, удобно и главное надежно

linker
А я не соглашусь с тобой. В последнем проекте мне стояла задача загружать excel-файлы, парсить и сохранять нужную информацию для дальнейшей обработки. А как хранить XLS на сервере для удобного парсинга? Правильно - в массиве. Вот тут файлы и победили. serialize + base64_encode правят миром.

в базе иногда приходиться создавать новый таблицы, а в файле все можно запихнуть ))одним разом например друзья пользователя

SQL - это стандарт и хорошая традиция, а как известно - "Лучшее - враг хорошего".

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

Bossmen
В базе тоже так можно делать, просто достаточно немного мозгами пораскинуть. Вообще вполне достаточно 1 - 3 таблиц для функционального сайта. В одной таблице можно хранить всю информацию, касающеюся юзверей к примеру.

Пример:

ID | PARAM | VALUE
1 | login | fuckinLogin
1 | fio | Педрос

Ну вы поняли...

Snus конечно, я примерно так и делаю. Более того весь язык простых запросов нетрудно написать и не зависить не от каких sql.

linker
Я всего-лишь хотел сказать, что с большим потоком данных лучше все-таки смотреть в сторону файлов.

А что касаемо фотографий - тут безусловно лучше хранить данные в мускуле, там писюков-то всего-ничего - Id, pathToImg, date ну и возможно tmp_name и file name

Мускул имеет ограничение на количество записываемой информации в таблицу (точнее в ячейку) , к примеру мой массив в 100 000 позиций напрочь отказывался записывать. А файлу хоть триллион запиши - ему от этого холоднее не станет.

Snus
С большим потоком данных лучше вообще переходить на Си и иные базы данных, нежели MySQL.

linker
Зачем? PHP и MyQL отлично справляются. Это все равно, что сказать плавцу - не можешь получить золото на соревнованиях - иди занимайся боксом.

linker
Но для простых проектов, без гектаров в одной ячейке (99% сайтов) SQL всеже излишне наворочен.

LRCenter
Для сайтов-визиток согласен, для хоумпагов аналогично, для всего остального более или менее серьезного - разумно использование базы данных.

linker разумно-то разумно, вопрос каких? Та же SQLite, и ей подобные библиотеки, куда интереснее неповоротливого mySQL-я.


Смотри какая подборочка http://www.cmsbezmysql.ru/ ,и это тенденция.
Красота!

Фигли лясы точить, слабо на файликах получить данные, которые можно получить используя следующий SQL-запрос в MySQL

SELECT 
    `Objects`.`Id`, `Objects`.`Name`, `Publications`.`PublicationCaption`, `Issues`.`IssueCaption`, `States`.`StateCaption`, `Users`.`UserFullName`,
    DATE_FORMAT(`Objects`.`ObjectCreated`, '%d.%m.%Y %H:%i:%s'),
    DATE_FORMAT(`Objects`.`ObjectModified`, '%d.%m.%Y %H:%i:%s')
FROM 
    `Objects`
LEFT JOIN `Publications` ON `Publications`.`Id` = `Objects`.`ObjectPublication`
LEFT JOIN `Issues` ON `Issues`.`Id` = `Objects`.`ObjectIssue`
LEFT JOIN `States` ON `States`.`Id` = `Objects`.`ObjectState`
LEFT JOIN `Users` ON `Users`.`Id` = `Objects`.`ObjectModifier`
LEFT JOIN `Features` ON `Features`.`Id` = `Objects`.`ObjectFeature`
WHERE
    `Objects`.`ObjectType` = 'Layout'
ORDER BY
    `States`.`StateOrder` ASC, `Features`.`FeatureOrder` DESC

???

linker, золотые слова!
а вот про SQLite

• не рекомендован для баз большого размера (эксперты не рекомендуют более 200 Мб);
• есть только два типа данных – целое автоинкримент и строка (всё остальное – эмулируется через строки);
• не предназначен для многопользовательского использования (хотя это и возможно).

И это относится к работе с файлами. Те же самые проблемы.

linker
Такие страсти не часто увидишь, это как раз 1%


hellmin
Не представляю себе на рядовом сайте БД больше 200Мб.

LRCenter
Это банальщина, ты думаешь в каком-нибудь инет-магазине нет что-то подобного? Ошибаешься. Интересно, сколько весит база этого форума? И как бы стабильно и быстро он работал, используй он файлики.

Такие выборки в банальном магазе не встретишь. Яндекс-маркет какой-то

не пойму о чем спор?????? Люди, если вы считаете что использовать файлы, куда лучше БД, ИДИТИ УЧИТЕ ХОТЯ БЫ ПОПОВА!!!!!! Он хоть в этом верно поступил, использует БД!!!!

linker удивляюсь, как у тебя еще терпение хватает доказывать ......

linker
Во первых не обязательно все хранить в одном файле. Для каждой ветки форума может быть один файл, или для каждой темы, например.

А интересно правда сколько весят БД этого форума?

Ну вот, начались грубости
Простите, но в таком не участвую.

LRCenter
Хорошо упростим ситуацию

SELECT 
    `Tovars`.`Id`, `Tovars`.`TovarName`, `Categories`.`CategoryName` 
FROM
    `Categories`
INNER JOIN `Tovars` ON `Tovars`.`TovarCat` = `Categories`.`Id`
WHERE
    `Tovars`.`TovarCount` > 0
ORDER BY
    `Categories`.`CategoryName` ASC, `Tovars`.`TovarName` ASC

или тоже сложно для простого сайта?

linker
На чем ты хочешь чтоб я сделал выборку? На простом php?

Прокоментируй пожалуйста sql-запрос (я плохо знаю sql-семантику).

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

В моем случае весь код будет таким

mysql_connect(...);
mysql_select_db(...);
$resource = mysql_query($query);
while($data = mysql_fetch_assoc($resource))
{
    echo "...";
}

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

А структура БД?

Snus
Я хочу видеть, что файлики лучше чем бд.

LRCenter
Структура здесь не важна.

linker
Ровно также как я тебя попрошу реализовать сохранение 1000 строк в каждой строке по 60 позиций. Другими словами массив вида:

   0 =>
     0 => 0
     1 => 1
     2 => 2
     ...
   1 =>
     0 => 0
     1 => 1
     2 => 2
     ...

и тд...

Snus
Не понял ничего.

linker
С удовольствием сделаю это, но только чуть позже, используя свою собственную библиотеку (заодно будет стимул ее дописать, а то все лень). Не закрывайте тему!

Нахрена мне нужно хранить значения из экселя, если есть эксель. Чем таблица эксель отличается от таблицы базы данных?

LRCenter
А сколько строк кода в твоей библиотеке? У меня всего 7 с учетом {} и без всяких библиотек.

linker
А сколько строк в mySQL? Думаю мег на 10-15 потянет.

Посмотрим еще что ресурсов жрать меньше будет
И работать быстрее!

Ты видимо не представляешь для чего нужна таки БД. В твоем случае пришел эксель, обработали и поминай как звали. БД - база данных - система долговременного/постоянного хранения данных.

Ну и холивары тут заварились

Snus
Какая посещаемость ресурса? Один-два оператор-таможенник в сутки?

Я думаю, база лучше, и с ей проще обращаться чем с файлом, так что я за БД

Snus
Чтобы хранить твои значения в базе хватит одной ячейки text, просто массив полученный из файла обработать функцией serialize и жить спокойно.

linker
40 сотрудников. Этим скриптом пользуются не меньше, чем Альтой и Бизнес-ПРО

hellmin
Внимательнее прочитай мои предыдущие посты. Так сказано было, что не возможно в TEXT запихнуть такой объем, в MySQL есть ограничение.

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

Snus
Там есть типы полей LONGTEXT и LONGBLOB.

linker
Вот тогда становится вопрос - что быстрее и лучше? Использование longtext в MySQL, да с таким потоком данных - мускул просто задохнется. Его лучше использовать для более практичных решений: пользователи, товары, страны и тд...

Snus
А ты проверял?

linker
А ты как сам думаешь?

Товарищи, вопрос заходит в тупик. Нельзя сказать что лучше файлы или Мускул - для обыденных задач - естественно Мускул выигрывает по всем параметрам, но бывают ситуации, в которых пытаться решить задачу средствами мускула - это изобретение велосипеда. Зачем заморачивать с лонгтекстами, если можно банально хранить все в файлах? Не находите?

Snus
Знаешь, кода я незнал вообще что такое правильная база, таблица, и что такое правильный и хороший запрос которым можно убрать 50% лишнего пхп кода, я тоже был за файлики, теперь без БД жить не могу.
и кстати, по поводу обьемов MySQL

Renden

TEXT - 65535 символов
TINYTEXT - 255 символов
MEDIUMTEXT - 16777215 символов
LONGTEXT - 4294967295 символов
CHAR - 1-255 символов

Слышал о таком?

Snus
И что? Это размеры типов полей. У тебя много эксельников с размером более 4 гигабайт? Какой у тебя средний размер массива в байтах(килограмм, метров, гигов)?

Snus
Ага и еще varhar и также числовые значения типа int, bigint но извени меня в 1 ячейку смысл записывать такое количество информации, база для того и нужна чтоб все было по полочкам.

linker

Ну вот, запиши около 1000 таких ExcelBody и поработай одновременно на 40 компах

	function genTable($rows = 400, $cols = 50){
		for($i = 0; $i <= $rows; $i++){
			for($i2 = 0; $i2 <= $cols; $i2++){
				$ExcelBody[$i][$i2] = $i.$i2;
			}
		}
		return $ExcelBody;
	}

	$ExcelBody = genTable(10000, 100);

Ты фанат, на один массив только 100 метров памяти уходит, а это не считая того, что есть еще эксель и либа которая работает с этим экселем и тоже выжирает памяти немеряно. 40 человек да при таких аховых объемах, видимо у таможни хорошие серваки, либо кто-то лукавит.

linker
Ну приврал, это и коню понятно. Файлы идут примерно от 100 до 1000 строк по 40 - 50 столбцов. Потом большой, один сотрудник за день загружает около 3 - 5 таких файлов и сцуко активно с ними работает.

Нахрена их куда-то грузить, когда можно открыть в экселе и работать с ними? Visual Basic там есть, можно хреначить автоматизацию почище чем на вебе, да и дешевле выйдет.

linker
Нельзя, серваке в Германии стоят, а расчетчики в Москве.

Бабло отмывают?
Взял файл в Москве, открыл у себя в экселе, запустил макрос, писанный на Visual Basic и получил результат.

linker
Такой ты простой Ты себе слабо представляешь, что такое таможня. А откуда макрос будет брать цены, коды и описания к товарам? Декларация, сертификации и тд? При том, что это закрытая и закодированная информация?

Я не знаю как работает таможня, но и ты не представляешь что есть VB сейчас.

Походу, я в глухом игноре у господ

linker
Проект не должен зависить от локальной машины (имею ввиду ПО на локальной машине). Он должен быть кросс-браузерным и доступным с любого компа и любой точки земли. Хоть об бабы зины из Хрюпинска. Организуешь макросами?

LRCenter
С файлами существуют следующие проблемы:
1. Прогиб дисковой системы по иопсам.
2. Гемморой великий при одновременном доступе.
3. Сложность выборки данных, добавления, редактирования, удаления и т.п.
4. Высокая нагрузка на PHP, т.к. Мускул по-любому работает быстрее, чем тоже самое сделанное на PHP.
5. Куча всего еще.

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

Snus
А что, у нас в таможенниках работают бабы Зины из Хрюпинска? Есть такая бойда, называется грубо говоря терминал, т.е. большой сервак, на который ходят юзверя и получают удаленно свой виртуальный компутер. Почитай на предмет Citrix Metaframe.

linker

linker
А пункт про не зависимость от ПО забыли ужо?

linker

Понятно, обленились тут все понимаешь: фреймворки им всякие подавай, Сервера БД.
Гибкость и оптимальность решений от того страдает.

Snus

LRCenter

linker
Проект сейчас активен и в данный момент в нем жмутся 40 рыл, сервак ни прыгает, ни плавает, ни падает. Сам лично попробовал сейчас загрузить 206 строк по 40 столбцов, на саму обработку тратятся миллисекунды, а вот на построение таблицы в HTML занимает около 3-4 секунд.

У меня текущий проект вот только-только более или менее запущен в работу, базы уже весят почти 3 гига, объем служебных файлов (Pdf, Indd, различные превьюхи) под 400 гигов. Среднее время генерации страницы в пределах 0.2 - 0.8 секунды. При этом фоном работаю процессы репликации данных, генерации индизных-полос в PDF и отжим первью полос. Плюс очень много тискается данных с удаленных 5 MySQL серваков и FTP.

linker
Ну что я могу сказать, "Сам себя не похвалишь - никто не похвалит" Это все прекрасно, вызывает только уважение. Но если этим самым ты хотел намекнуть, что мои скрипты жуть как тормозят - то ты явно не внимательно читаешь, что я пишу Сам скрипт выполняется какие-то миллисекунды, а вот построение html - занимает время. Тут уж никуда не денешься апач и браузеры жуткая весчь.

Snus
Тут хоть полностью разгрузи сервак, напиши обычный *.html файл и встань туда таблицу на 400 строк по 60 столбцов. И посмотри время загрузки страницы.

http://www.hotscripts.com/forums/php/20194...l-database.html

Вот интересная полемика. Обратите внимание на мнение эксперта сообщества:

LRCenter
Дык кто ж спорит что нельзя реализовать на PHP вопрос встанет колом у начальства, увольнять тебя или нет, после очередного падения сайта.

linker

если даже при flat-file что-нибудь и упадет, то вырубится только фрагмент сайта за который отвечал поврежденный файл (восстановил потом из бэкапа и порядок), а sql умирает капитально и целиком

LRCenter
Ты видимо не понимаешь о чем речь. Есть файлик с юзверями, у них есть значение даты последнего посежения сайта, одновременно заходят два юзверя и пытаются эту дату обновить и сохранить результат. Вопрос, что будет?

Умножь 50мсек(чем больше данных, тем выше время ожидания, а если еще вспомнить про дефрагментированность данных на диске, и про своп, потому что все это барахло надо держать в памяти и прочее) на количество юзверей, самый последний тебя обматерит.

По сравнению с файлами тормоза с SQL - цветочки.

LRCenter
Ну да, дата своя, а фалик один. Зашел первый юзверь, считал данные, зашел второй юзверь тоже считал данные. Оба юзверя считали данные одновременно, обновили свои ячейки и сохраняют результат обратно. Заметь, что первый юзверь не знает, что зашел второй и тоже что-то обновляет, аналогично и второй. Каждый работает со своими считанными данными из файла. Теперь они сохраняют все то барахло, что было считано в файл. Первый пошел, записал (помним, в считанных данных первого, нет того факта, что зашел второй), пошел второй - записал (у которого тоже в считанных данных не отражен факт захода первого). Что будет?
Читаем построчно из файла? Да выход, но, что мы видим? Чтобы найти нужного юзверя в файле, необходимо в цикле прочитать часть, а то и весь файл. Потом найдя себя, обновить значение и опять нужно найти нужную строку, а потом еще как-то впихнуть туда новое значение. Отцы оптимизации переворачиваются в гробах.

linker

А что внутри sql-я это как-то иначе происходит?

LRCenter, бывает что лучше вся база упадёт чем только её часть.

Snus
Ты говоришь о своем проекте, значит пример логично относится к твоему проекту. Как и я говорю о своем проекте, а потому примеры привожу реальной работы, а не вымышленной и абстрактной. Ощути разницу, между реальными данными по времени, объемам и прочее в реальном времени, и придуманными от балды примерами с неизвестными исходными данными и результатом в определенных рабочих условиях и факторах.

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

Окей, у тебя есть 100 эксельников, оператору нужно срочняком что-то найти, тебе придется перемалывать все это барахло и как на зло нужно окажется в самом последнем.

LRCenter
Я не разрабатывал MySQL, потому не могу сказать что там происходит. Но мне это и не нужно, в случае когда два пользователя одновременно заходят на сайт, а вот тебе приходится костыли подставлять, чтоб вся система не гикнулась в первые минуты.

Gradus, бывает, но не часто. Что наиболее вероятно? К примеру отрубились комментарии к очень обсуждаемой статье на новостном сайте. Но сама статья то осталась, ее можно читать, можно сообщить админу через форму обратной свзязи о таких проблемах, да и скрипт сам сообщит. Минимизация ущерба в действии.

А если sql упал - это fatal error/ и полный пралич и кома веб-системы.

За все мои 5 лет общения с PHP, MySQL и более 15 лет программирования и администрирования гораздо чаще ломалось железо (харды бились), чем падал мускул (причем фатально с подключением бэкапов он упал только один раз, три раза кончалось место на диске, раза три-четыре крошили индексы, которые за несколько секунд восстанавливались). Вывод, стоит ли уповать на то мускул гораздо быстрее фатально упадет, чем накроется жесткий диск со всеми файликами с данными?

Snus

Я убежден что sql, наиболее простое и удобное рашение для большинства проектов и разработчиков. Но не уверен в его оптимальности для большинства проектов.

Чтобы не быть голословным и не ждать до конца месяца (от своих слов не отказываюсь - покажу выборку на файлах), давайте проведем эксперимент по сравнению скорости работы flat-file и sql на малых и средних объемах данных.

От себя предоставляю специально написанную по случаю функцию (простите за стиль и прочее - очень сырая):

#Перезапись значения строки или ячейки
function boxCSVRep($filedb, $modrep, $idnum, $idkey, $numrcellx, $newval, $repeat, $rnrep){
ignore_user_abort(true);
set_time_limit(0);
if($modrep=="cell" or $modrep=="line"){
$idnum=$idnum - 1;
$numrcell=$numrcellx - 1;
$needle=0;
$text=file($filedb);
if ($modrep=="cell"){$newval=str_replace(";","<->",$newval);}
$newval=str_replace("\r\n",$rnrep,$newval);
$newval=str_replace("\r",$rnrep,$newval);
$newval=str_replace("\n",$rnrep,$newval);
foreach ($text as $msv){
$cellnum=explode(";",$msv);
if($cellnum[$idnum]==$idkey){
if ($modrep=="line"){$gorep=1;}
else{
if ($numrcellx > count($cellnum) or $numrcellx < 1){echo "Cell num. $numrcellx is not exist."; $gorep=0;}
else {$gorep=1;}}
if ($gorep==1){
$f_arr = file($filedb);
if ($modrep=="cell"){
$cellnum[$numrcell]=$newval;
$f_arr[$needle]=implode(";", $cellnum);}
else {$f_arr[$needle] = $newval;}
$f=fopen($filedb , "w");
$f_arr=str_replace("\r\n","",$f_arr);
$f_arr=str_replace("\r","",$f_arr);
$f_arr=str_replace("\n","",$f_arr);
for($i = 0; $i < count($f_arr); $i++){
if (flock($f,LOCK_EX)){
fwrite($f , $f_arr[$i]."\r\n");
flock($f,LOCK_UN);}}
fclose ($f);
if($repeat!=1){break;}}}
$needle++;}}else {echo "Set mode is not correct.";}}


#Параметры:Путь к csv, заменять строку или ячейку("line" или "cell"), номер ключевого параметра для идентификации в строке(ячейки) (c 0), ключевое значение, номер заменяемой ячейки, новое значение, повторить много раз(1\0) по умолчанию(пустое поле) - не повторять, замена для переноса строки
#boxCSVRep("base.csv","cell","1","id1","5","Н овое значение","0","<br>");

Твой код делает тоже самое, что и мой представленный на странице нумбер 3 cего топика?

Повторю, кстати, его полностью вместе с запросом

<?php

mysql_connect(...);
mysql_select_db(...);
$query = "SELECT 
    `Tovars`.`Id`, `Tovars`.`TovarName`, `Categories`.`CategoryName` 
FROM
    `Categories`
INNER JOIN `Tovars` ON `Tovars`.`TovarCat` = `Categories`.`Id`
WHERE
    `Tovars`.`TovarCount` > 0
ORDER BY
    `Categories`.`CategoryName` ASC, `Tovars`.`TovarName` ASC";
$resource = mysql_query($query);
while($data = mysql_fetch_assoc($resource))
{
    echo $data['TovarName'] . '<br>';
}

?>

Ты программист? Я думаю программисту беглого взгляда будет достаточно, чтобы понять где оптимальнее, удобнее, быстрее и прочее.

Нет, пока я всего лишь скромный хэлоувордщик

Нет, это не выборки - это другая функция - это замена ячейки или строки в таблице формата csv/

Как на выборках-то проверить транззакции и коллизии - без записи же.

Сравни c моими двумя строчками обновления значения указанного поля

$query = "UPDATE `Tovars` SET `TovarPrice` = '154.50' WHERE `Id` = 1023";
mysql_query($query);

Ты продолжаешь уверенно считать, что твой код отработает не медленнее моего?

Тебя за язык никто не дергал

linker, LRCenter
Да о чем вы спорите?!?! Естественно Мускул быстрее и практичнее для таких задач банальных, это уже удалось выяснить в ходе дискуссии. Интересно узнать о больших объемах (на моем примере). Я на практике САМ СЕБЕ доказал уже, что файлы отрабатывают в 1.5 раза быстрее, чем Мускул, хотелось бы ваши версии услышать. На примере огромных таблиц с данными а-ля Эксель. Грубо говоря - нужна имитация экселя на стороне сервера + доп. подсчеты, подбор сертов, деклараций, определение стран и тд.

Snus
Мой проект далеко не банален, однако в целях практичности, удобства, скорости, оптимальности, рациональности и прочих умных слов я работаю именно с MySQL.

linker
Мускул лучше всего использовать, как я уже говорил, для обыденных моментов, а вот сотни Гб гонять по мускулу только потому, что это удобно. В моем случае это спорно.

В мускуле я держу информацию по загруженному файлу, а данные из экселя в файле.
eNum | BPnum | clientName | goodsName | excelName | userId | data | del
По идентификатору eNum я беру файл из директории, название файла {eNum}.db, содержимое которого - это закодированная сериализация массива. Т.к у меня автосохранение при каждом действии с таблицей - делать эту таблицу на мускуле - бесмысленно, ибо это будет сжирать очень много памяти мускула и что вызовет лаги в остальных скриптах программы (а это только 1\10 часть от всей программы). Повторюсь - fopen`у много времени не нужно, чтобы считать файл, ровно также, как и записать. И при этом пхп не сильно забивается (память, я имею ввиду). Так вот - стоит ли каждый раз посылать UPDATE `ffff` SET `motherFucker` = 'ТУЕВА_ХУЧУ_ИНФЫ' в Мускул? ТУЕВА_ХУЧУ_ИНФЫ = сериализ массива, чтобы забить нафик всю память мускула (ну я уже повторяюсь). И еще не забываем, что фирма большая и помима моего проекта на мускуле крутятся видеонаблюдение, хелпдеск и еще куча разных приблуд.

linker
У тебя либо комплексы, либо ты читаешь через строчку. Я не называл твой проект банальным, я сказал

Мускул быстрее и практичнее для таких задач банальных

$query = "UPDATE `Tovars` SET `TovarPrice` = '154.50' WHERE `Id` = 1023";
mysql_query($query);

Если пальцем ткнуть - понятнее?

Snus
Я тебе кажется приводил свои цифры, что на данный момент только на одном мускул сервере у меня уже под 3 гектара данных, таких серваков у меня еще 5 штук. Время отдачи страницы я тоже вроде приводил. Нагрузка в 500 юзверей тоже оглашалась. Объемы трафика также были раскрыты. Неужели программист, по идее обладающей логикой, не может переварить всю эту инфу и понять, что эффективность начинает оформляться при проектировании и усугубляться при реализации. Если ты неверно спроектировал свое приложение изначально, то это не значит что мускул в твоем случае проигрывает.

linker
Вот я уже второй день пытаюсь выпытать от тебя предложение по проектировке, а ты только защищаться начинаешь, тем самым в тупик разговор ведя. Я тебе уже задачу описал - решение на мускуле так и не увидел. С описаниями почему лучше. версия с longtext? - Пипец, гениально. От того и пошла дискуссия почему лонгтекст, а не файлы? "Не было ни единого разрыва" - вот что мне напоминает наш разговор.

linker
А причем тут размер кода?

В твоем случае нагрузка пойдет через sql, надо чтобы sql и web-серв были на одной машине.
Проверь. Доверяю твоей честности.

Я тебе озвучил решение и не раз, на примере своего проекта. Смотри, верстак верстает полосу в InDesign, журналюга и прочие редактора, корректировщики и прочие участвующие люди пишут и правят статьи в InCopy. На выходе может быть один файл полосы и с десяток файлов статей, которые заверстаны на полосу. Как ты думаешь, какова может быть реализация просмотра этой полосы (причем сами статьи ничего не знают о том, что они куда-то заверстаны, это просто отдельные файлы на диске, они даже могут в разных папках находиться)? При условиях выборок:

1. Хочу видеть инфу обо всех статьях на полосе + полосу и инфу о ней.
2. Хочу видеть только статьих находящиеся в корректуре или на верстке или у редактора.
3. Хочу видеть только рекламные статьи, инфорграфику и вариантов масса.

достаточно и этого.

P.S. файлы статей это обычные XML.

linker
Да чего бисер метать я видел наверно уже пяток челов которые с пеной у рта доказывали что файлы лучше пока не научились запросы писать. Для тех кто в танке БД лучше чем фалы хотя бы по тому что они ПРЕДНРЗНАЧЕНЫ для хранения массивов данных кучу челов не спят ночами думают как бы сделать самый быстрый поиск в ихней БД. А файл это это просто место на диске в памяти не имеющий не какой структуры да такой штуки как индексы у них нет.

детишки вы знаете, что такое индексы ??? это каталог как в библиотеке чтоб книги было возможно найти.

Basili4
Это ты сейчас кому столь познавательную информацию написал?

linker
Это кому ответ был? На мой вопрос так и не последовал ответ. Ты просто не знаешь. Признайся уже и закончим эту пустую дискуссию. А то уже не диалог, а монолог получается в лице меня.

Basili4
Я просто хочу, чтобы люди своими головами осмыслили свои убеждения и приняли правильное решение - изучать язык SQL-запросов, настраивать и оптимизировать MySQL для увеличения производительности.

Snus
Повторю свой пост, раз ты не понял, что он предназначен для тебя

Я тебе озвучил решение и не раз, на примере своего проекта. Смотри, верстак верстает полосу в InDesign, журналюга и прочие редактора, корректировщики и прочие участвующие люди пишут и правят статьи в InCopy. На выходе может быть один файл полосы и с десяток файлов статей, которые заверстаны на полосу. Как ты думаешь, какова может быть реализация просмотра этой полосы (причем сами статьи ничего не знают о том, что они куда-то заверстаны, это просто отдельные файлы на диске, они даже могут в разных папках находиться)? При условиях выборок:

1. Хочу видеть инфу обо всех статьях на полосе + полосу и инфу о ней.
2. Хочу видеть только статьих находящиеся в корректуре или на верстке или у редактора.
3. Хочу видеть только рекламные статьи, инфорграфику и вариантов масса.

достаточно и этого.

P.S. файлы статей это обычные XML.

linker
Да? И где же тут предложение по реализации моей задачи? "КуЧа БуКаВаК" я вижу только.

Snus
Ты программист или кто? Разве не видишь очевидного и единственно верного решения?

linker
Все ясно с тобой. Я решение вижу и оно уже как полгода работает без сбоев. А вот ты не смог внятно рассказать хотя бы десятую часть того, как бы ты хранил информацию в Мускуле. Дискуссию на эту тему с тобой прекращаю, ибо уже бессмысленно. longtext - вот твое мнение по поводу того, как бы ты хранил, ты его озвучивал в начале. С той мертвой точки мы так и не сдвинулись. Мой ответ на твою реализацию : лонгтекст мне не подходит. Соответственно, предложить ты так ничего и не смог. В итоге в данном соревновании победили файлы.

А общий ответ по сабжу - "Что выбрать файл или база данных" - это палка о двух концах. В каждом случае свой подход. Но в 95% случаев конечно Мускул.

Snus
В моем случае победил TEXT. Ибо, найти в 10 тысячах статей (на данный момент), те в которых присутствует слово "Путин" в базе будет в 100 раз и более быстрее, чем я буду искать это слово в каждом файле.

Разум не восторжествовал, а жаль.

linker
Ты очень невнимательный. Данные зашифрованные, посмотрел бы я на тебя, как ты будешь искать слово Путин. Даже если ты будешь искать по зашифрованному слову Путин, он тебе еще выдаст пару тысяч непонятных словосочетаний. Удачи!

Все понятно, моск мы включать не хотим, удачи.

Как ни крути, но найти "Путин съел селедку", зашифрованную, например, в мд5 по слову "Путин" не получится как бы ты не пыхтел.

Snus
Хотел бы я видеть, как ты расшифровываешь md5-хэши своих эксельников.

linker
Мда... еще раз подтвердил мою теорию о том, что ты читаешь только отдельные куски текста.
Я написал "например, в мд5", не буду же я тебе все детали раскрывать. Если был бы сообразительным, не придрался бы к слову МД5, а понял о чем я тебе говорю. Факт остается фактом. Твои 5 лет общения с Мусклум с треском упали в моих глазах.

Snus
Малыш иди учи уроки. Я тоже судя по всему не сообразительный потому что меня также заинтересовал вопрос как же ты из хеша будешь текст восстанавливать.

Я бьы с радостью посмотрел как завалится вся твоя возня на фалах при записях едва достигших 1 миллиона. оффтоп жалко Федя к нам не ходит уже он тоже пяткой в грудь стучал никаких БД пока экзамен по БД не сдал. ага.

Basili4
Ты выражаться подобным тоном со своими малышами будешь, а здесь соблюдай дисциплину, выскочка.

Snus

Basili4
"Да ты умен не по годам". Последний этап эволюции явно прошел мимо тебя.

Snus
ага я не "Эльф 80 уровня" в отличии от тебя.

Basili4
Своим поведение ты доказываешь абсолютно противоположное.

Snus

Snus, с md5 ушёл в максимализм
Да хорош , Snus и linker вы указываете друг другу на минусы, а общее сравнение сделать не хотите.Я вот лично не вижу в файлах каких-то моментов которые справятся лучше чем mysql, кроме как тупо текст огромный (с которым не надо сложные действия выполнять) показывать и вообще те сайты которые бд делают на файлах похожи просто на бардак с чем работать не особо хочется, хотя может я просто привык к mysql

DmitryOpalev
Я ему всего-лишь намекал на то, что чем не шифруй, поиск по мускулу будет перекрыт. А МД5 - это первое, что мне на ум пришло. Хоть даже своим шифрованием пользуйтесь, разницы нет - одностороннее шифрование или нет.

Gradus
А я не говорил, что сайты на файловых БД это круто. Я лично против таких. Я пытался доказать, что хранить многотонный массив лучше в файле, чем засирать столь полезную мускул.

А где тема была foreach VS... я её мимо глаз пропустил...

Snus, ну тут другие факторы надо учитывать , а так наверное согласен

Я плакалъ)

Я не представляю, как это, держать БД в папке, которая предназначена для хранения файлов скриптов)

Да и потом же, мускул - это те же самые файлы, в которых хранятся эти данные) Зачем заного создавать велосипед? Лишняя мутора) Да и в добавок, файлы повредить проще, чем структуру БД, которая, при грамотном обращении, будет недоступна пользователю)

В общем, хоть утопчите, я за Мускул)

linker

LRCenter
Уф, в целом тут 10 страниц срача))
Да смысл это обсуждать, это разница как windows и linux.. Виндузятники будут кричать виндовс удобен, на виндовс игры.. линуксойды будут кричать про стабильность, отсутствие вирусов и тп...идею вы поняли. Смысл в том что под РАЗНЫЕ задачи используется разный функционал, будь то файлы, будь то база. Все завсисит от удобства непосредственному создателю скрипта, с чем ему удобнее работать.

Renden
Извини, а в чем разность задач проявляется при вопросе где накапливать и хранить данные?

Renden
Согласен с вами, по большому счету функционал flat-file (при хорошей библиотеке) приближается к sql, и чем пользоваться (для большинства задач) в основном вопрос удобства и привычки.

Я склоняюсь к файлам, потому что люблю идейный минимализм, и мне приятно осозновать что на один внешний элемент влияющий на работу меньше. Господа, которые учились в тех.вузах и внимательно слушали лекции по ТРИЗ-у меня поймут.

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


Хочу еще поблагодарить публику php-форума за вполне себе культурную дисскусию, особенно linker-а за его терпение: на просторах сети встречаются холивары по этой теме переросшие в инквизицию и травлю со всякими оскорблениями и проч. инакомыслящих

LRCenter
Да но тебе пришлось нарисовать самом функцию boxCSVRep(), так что тут не одна строка тобой написана.

linker
Понятно что пришлось, но она весит всего <2кб и это мой sql- мнеже не придется переписывать ее каждый раз так что трудоемкость работы с ней вполне сопоставима с sql.

Вся библиотека в итоге не должна превысить 30кб, а sql весит больше 10Мб, поскольку он мне не нужен экономия пространства очевидна

LRCenter
но твоя либу надо загружать в проект. А субд работает сама по себе. Есть не полохой тест для выявления качества твоей либы. Сделай выборку из из 3 таблиц по 1 миллиону записей. и сделать тоже самое на любой СУБД и сравни время выполнения запроса. Я лично не сомневаюсь в том что результат покажет чего стоит твоя либа. и закроет весь этот холивар раз и на всегда.

Придерживаюсь БД

Basili4
Я же оговорил - что библиотека для малых и средних объемов данных. А то о чем говорите вы требует оптимизации и специальных разработок. В нуждах рядового разработчика web-сайтов такое нечасто встретишь.

LRCenter
комментариев на форуме может быть не меньше или будешь создавать для каждого топика отдельную таблицу с комментами.

Basili4
Это остается на совести разработчика форума, который будет использовать мою библиотеку.
Ну если-бы я разрабатывал форум общего назначения, то наверное так - для каждой темы отдельный файл, пожалуй это наиболее оптимально.

Мой огромный совет ребятам-любителям файлов. Напрягите свои извилины, потратьте время, разберитесь, почитайте книжек на тему теории баз данных. Прочитав и вникнув вы поймете, что неизбежно ваших мозгов, сил и времени не хватит никогда, чтобы разродится действительно качественной поделкой, сравнимой с современными разработками в сфере хранения и обработки информации, в частности баз данных. Все ваши решения изначально не оптимальны, тяжеловесны, медленны, ресурсоёмки. Их сложно поддерживать, в них сложно разбираться, из них формируется контент www.govnokod.ru . Выучите теорию, научитесь писать SQL-запросы и вы поймете, что это добро, а все что вы делали до этого годится лишь для страниц "Привет Я Вася Пупкин, это моя странца" с максимальным посещением 1 человек в месяц.

linker
Вас послушать, так все новое неизбежно поподает на govnokod.ru
Как же тогда оно появляется? Все новаторы говнокодеры по определению. Такая вот прикольная этика в среде программеров

Вы про эволюцию слышали? Она ведь не только в природе бывает, а в технических системах тоже. sql морально устаревает, это очевидно, ему на смену приходит множество разных парадигм, например про noSQL слышали? http://ru.wikipedia.org/wiki/NoSQL

Про конвергентную и дивергеную эволюцию может знаете?
Так почему бы не попробовать такой вариант? Есть же sqlite, например, но он на C, почему бы не сделать тоже самое на php? Понятно что будут недостатки, а у чего их нет? Будет и своя ниша для применения - я уверен.

А теперь извините, мне некогда - пошел писать библиотеку, поговорим по факту

LRCenter
И про Васю Пупкина вы конечно загибаете)

Понятно что flatfile в чем-то могут уступать sql, но не настолько. Есть куча CMS на файлах в том числе реализующие одновременный доступ, и версии - очень надежных и т.п. - например wiki-движок DokuWiki - http://ru.wikipedia.org/wiki/DokuWiki


---
http://en.wikipedia.org/wiki/List_of_conte...agement_systems

Обратите внимание на раздел "File/flat file" - там с десяток серьезных CMS представлено - значит есть своя ниша.


А среди wiki-движков на файлах вообще чуть-ли не половина:
http://ru.wikipedia.org/wiki/Вики-движок


Так что знаете: субд приходят и уходят, а файлы остаются