Політичний ФОРУМ
Спорт/Авто/Техно => Тема розпочата: fam від 19 листопада 2017 17:40:02
-
Есть ли в PHP какие-то готовые средства для сброса сгенерированной структуры данных в файл в том виде, в котором его можно, например, через include использовать в дальнейшей работе?
шото читаю, но не нахожу.
если в var_dump такое:
["table_comment"]=>
array(13) {
["controller_function"]=>
string(3) "atc"
["parent_table"]=>
string(4) "kegg"
....
то мне надо распечатать в файл такое:
$table_comment = array (
'controller_function' => 'atc',
'parent_table' => 'kegg',
....
то есть, в том виде, в котором я писал бы эту структуру в редакторе.
;o
-
fam, cкажи мне, какую именно структуру файла ты ожидаешь и неужели думаешь народ что то свое пилить будет или что тебе такой файл будет удобен? :laugh:
Все должно быть стандартным, потому гугли на тему JSON и XML, вот в один из этих форматов тебе и надо "сбрасывать". И это практически 100% самый правильный путь.
Быстрый поиск в инете и находим легкий путь к тому что тебе надо :
-----
$json = json_decode(file_get_contents($file),TRUE);
$json[$user] = array("first" => $first, "last" => $last);
file_put_contents($file, json_encode($json));
------
-
ще serialize є
-
fam, cкажи мне, какую именно структуру файла ты ожидаешь и неужели думаешь народ что то свое пилить будет или что тебе такой файл будет удобен? :laugh:
Все должно быть стандартным, потому гугли на тему JSON и XML, вот в один из этих форматов тебе и надо "сбрасывать". И это практически 100% самый правильный путь.
да не прошу я никого ничего пилить.
идея такая. При запуске скрипта происходит обращение к нескольким таблицам, чтобы создать страницу (контент, меню, breadcrumbs, и т.д.). Чтобы избежать лишних обращений к БД, хочу определить ряд данных в своего рода конфиге, который загружается по умолчанию. Мне кажется, что это выгоднее для производительности. Но постоянно помнить об этом трудно - забудешь и внесешь какие-то коррекции в таблицу, а файл этот забудешь. То исть , надо при каждом изменении, вносимом в мета данные таблицы, чтобы это автоматотом переписывалось.
напилить сам могу, но интересует, есть что-то уже или нет.
-
fam, cкажи мне, какую именно структуру файла ты ожидаешь и неужели думаешь народ что то свое пилить будет или что тебе такой файл будет удобен? :laugh:
Все должно быть стандартным, потому гугли на тему JSON и XML, вот в один из этих форматов тебе и надо "сбрасывать". И это практически 100% самый правильный путь.
Быстрый поиск в инете и находим легкий путь к тому что тебе надо :
-----
$json = json_decode(file_get_contents($file),TRUE);
$json[$user] = array("first" => $first, "last" => $last);
file_put_contents($file, json_encode($json));
------
надо познакомицца, спасибо
-
хм, я не прочел код сначала - там же из файла и в файл, но содержимое сначала надо создать. Короче, ладно, спасибо, разберусь.
-
fam, cкажи мне, какую именно структуру файла ты ожидаешь и неужели думаешь народ что то свое пилить будет или что тебе такой файл будет удобен? :laugh:
Все должно быть стандартным, потому гугли на тему JSON и XML, вот в один из этих форматов тебе и надо "сбрасывать". И это практически 100% самый правильный путь.
да не прошу я никого ничего пилить.
идея такая. При запуске скрипта происходит обращение к нескольким таблицам, чтобы создать страницу (контент, меню, breadcrumbs, и т.д.). Чтобы избежать лишних обращений к БД, хочу определить ряд данных в своего рода конфиге, который загружается по умолчанию. Мне кажется, что это выгоднее для производительности. Но постоянно помнить об этом трудно - забудешь и внесешь какие-то коррекции в таблицу, а файл этот забудешь. То исть , надо при каждом изменении, вносимом в мета данные таблицы, чтобы это автоматотом переписывалось.
напилить сам могу, но интересует, есть что-то уже или нет.
это ты что то дикое по моему пытаешься делать :D У тебя уже есть база данных и как и любая база данных - она наверняка расчитана на то что в нее будут ломиться, много и часто. А вот постоянно в файловую систему что то писать как ты хочешь - наверняка будут тормоза и лишние проблемы.
Не пытайся к машине где то снизу 5-е колесо добавить :D
-
хм, я не прочел код сначала - там же из файла и в файл, но содержимое сначала надо создать. Короче, ладно, спасибо, разберусь.
нет, в середине там содержимое показано, а именно массив. Первая строка пример как его загружать из json, а последняя - как его сохранять в json.
-
fam, cкажи мне, какую именно структуру файла ты ожидаешь и неужели думаешь народ что то свое пилить будет или что тебе такой файл будет удобен? :laugh:
Все должно быть стандартным, потому гугли на тему JSON и XML, вот в один из этих форматов тебе и надо "сбрасывать". И это практически 100% самый правильный путь.
да не прошу я никого ничего пилить.
идея такая. При запуске скрипта происходит обращение к нескольким таблицам, чтобы создать страницу (контент, меню, breadcrumbs, и т.д.). Чтобы избежать лишних обращений к БД, хочу определить ряд данных в своего рода конфиге, который загружается по умолчанию. Мне кажется, что это выгоднее для производительности. Но постоянно помнить об этом трудно - забудешь и внесешь какие-то коррекции в таблицу, а файл этот забудешь. То исть , надо при каждом изменении, вносимом в мета данные таблицы, чтобы это автоматотом переписывалось.
напилить сам могу, но интересует, есть что-то уже или нет.
это ты что то дикое по моему пытаешься делать :D У тебя уже есть база данных и как и любая база данных - она наверняка расчитана на то что в нее будут ломиться, много и часто. А вот постоянно в файловую систему что то писать как ты хочешь - наверняка будут тормоза и лишние проблемы.
Не пытайся к машине где то снизу 5-е колесо добавить :D
не, я же не о данных веду речь, а о мета-данных, которые не изменяются каждый день и даже месяц (а то и год).
а загрузить вначале несколько кБ продуманной структуры лучше, чем сделать пару-другую лишних обращений за бОльшим кол-вом данных, чем надо - интуитивно чую.
-
fam, cкажи мне, какую именно структуру файла ты ожидаешь и неужели думаешь народ что то свое пилить будет или что тебе такой файл будет удобен? :laugh:
Все должно быть стандартным, потому гугли на тему JSON и XML, вот в один из этих форматов тебе и надо "сбрасывать". И это практически 100% самый правильный путь.
да не прошу я никого ничего пилить.
идея такая. При запуске скрипта происходит обращение к нескольким таблицам, чтобы создать страницу (контент, меню, breadcrumbs, и т.д.). Чтобы избежать лишних обращений к БД, хочу определить ряд данных в своего рода конфиге, который загружается по умолчанию. Мне кажется, что это выгоднее для производительности. Но постоянно помнить об этом трудно - забудешь и внесешь какие-то коррекции в таблицу, а файл этот забудешь. То исть , надо при каждом изменении, вносимом в мета данные таблицы, чтобы это автоматотом переписывалось.
напилить сам могу, но интересует, есть что-то уже или нет.
работай с БД, не занимайся ерундой. Будешь файловую систему дергать - лучше не станет, просто организуй структуру БД так чтобы минимально считывать необходимые данные, правильные связи организуй и индексы и будет тебе счатье
-
да не прошу я никого ничего пилить.
идея такая. При запуске скрипта происходит обращение к нескольким таблицам, чтобы создать страницу (контент, меню, breadcrumbs, и т.д.). Чтобы избежать лишних обращений к БД, хочу определить ряд данных в своего рода конфиге, который загружается по умолчанию. Мне кажется, что это выгоднее для производительности. Но постоянно помнить об этом трудно - забудешь и внесешь какие-то коррекции в таблицу, а файл этот забудешь. То исть , надо при каждом изменении, вносимом в мета данные таблицы, чтобы это автоматотом переписывалось.
напилить сам могу, но интересует, есть что-то уже или нет.
это ты что то дикое по моему пытаешься делать :D У тебя уже есть база данных и как и любая база данных - она наверняка расчитана на то что в нее будут ломиться, много и часто. А вот постоянно в файловую систему что то писать как ты хочешь - наверняка будут тормоза и лишние проблемы.
Не пытайся к машине где то снизу 5-е колесо добавить :D
не, я же не о данных веду речь, а о мета-данных, которые не изменяются каждый день и даже месяц (а то и год).
а загрузить вначале несколько кБ продуманной структуры лучше, чем сделать пару-другую лишних обращений за бОльшим кол-вом данных, чем надо - интуитивно чую.
:laugh:
-
fam, cкажи мне, какую именно структуру файла ты ожидаешь и неужели думаешь народ что то свое пилить будет или что тебе такой файл будет удобен? :laugh:
Все должно быть стандартным, потому гугли на тему JSON и XML, вот в один из этих форматов тебе и надо "сбрасывать". И это практически 100% самый правильный путь.
да не прошу я никого ничего пилить.
идея такая. При запуске скрипта происходит обращение к нескольким таблицам, чтобы создать страницу (контент, меню, breadcrumbs, и т.д.). Чтобы избежать лишних обращений к БД, хочу определить ряд данных в своего рода конфиге, который загружается по умолчанию. Мне кажется, что это выгоднее для производительности. Но постоянно помнить об этом трудно - забудешь и внесешь какие-то коррекции в таблицу, а файл этот забудешь. То исть , надо при каждом изменении, вносимом в мета данные таблицы, чтобы это автоматотом переписывалось.
напилить сам могу, но интересует, есть что-то уже или нет.
работай с БД, не занимайся ерундой. Будешь файловую систему дергать - лучше не станет, просто организуй структуру БД так чтобы минимально считывать необходимые данные, правильные связи организуй и индексы и будет тебе счатье
шо значит дергать? по ходу фреймворк загружает пару десятков файлов минимум. обычный include
-
fam, cкажи мне, какую именно структуру файла ты ожидаешь и неужели думаешь народ что то свое пилить будет или что тебе такой файл будет удобен? :laugh:
Все должно быть стандартным, потому гугли на тему JSON и XML, вот в один из этих форматов тебе и надо "сбрасывать". И это практически 100% самый правильный путь.
да не прошу я никого ничего пилить.
идея такая. При запуске скрипта происходит обращение к нескольким таблицам, чтобы создать страницу (контент, меню, breadcrumbs, и т.д.). Чтобы избежать лишних обращений к БД, хочу определить ряд данных в своего рода конфиге, который загружается по умолчанию. Мне кажется, что это выгоднее для производительности. Но постоянно помнить об этом трудно - забудешь и внесешь какие-то коррекции в таблицу, а файл этот забудешь. То исть , надо при каждом изменении, вносимом в мета данные таблицы, чтобы это автоматотом переписывалось.
напилить сам могу, но интересует, есть что-то уже или нет.
работай с БД, не занимайся ерундой. Будешь файловую систему дергать - лучше не станет, просто организуй структуру БД так чтобы минимально считывать необходимые данные, правильные связи организуй и индексы и будет тебе счатье
смотри сюда: в обычном виде - примерно несколькоэтажный if else if...else и каждая таблица рассматривается конкретно. В моем случае - просто $table['columns']['url_title_field'], например
-
да не прошу я никого ничего пилить.
идея такая. При запуске скрипта происходит обращение к нескольким таблицам, чтобы создать страницу (контент, меню, breadcrumbs, и т.д.). Чтобы избежать лишних обращений к БД, хочу определить ряд данных в своего рода конфиге, который загружается по умолчанию. Мне кажется, что это выгоднее для производительности. Но постоянно помнить об этом трудно - забудешь и внесешь какие-то коррекции в таблицу, а файл этот забудешь. То исть , надо при каждом изменении, вносимом в мета данные таблицы, чтобы это автоматотом переписывалось.
напилить сам могу, но интересует, есть что-то уже или нет.
это ты что то дикое по моему пытаешься делать :D У тебя уже есть база данных и как и любая база данных - она наверняка расчитана на то что в нее будут ломиться, много и часто. А вот постоянно в файловую систему что то писать как ты хочешь - наверняка будут тормоза и лишние проблемы.
Не пытайся к машине где то снизу 5-е колесо добавить :D
не, я же не о данных веду речь, а о мета-данных, которые не изменяются каждый день и даже месяц (а то и год).
а загрузить вначале несколько кБ продуманной структуры лучше, чем сделать пару-другую лишних обращений за бОльшим кол-вом данных, чем надо - интуитивно чую.
не городи лишних сущностей. Даже если ты выграешь немного производительности (что ОЧЕНЬ сомнительно) - ты же себе яму роешь, на голом месте добавляя лишее в прогу. А потом окажется что ты например на диск D решил писать, а на очередной машине его просто не будет. Или например путь куда ты пишешь будет рид-онли или еще какая то фигня. И все будет валиться. :) Наоборот нужно уходить от юзания локальных ресурсов и валить все во что то стандартное, типа той же БД.
И вообще, не нужно пытаться оптимизировать то, что и так наверняка отлично оптимизируется в данном случае твоей базой данных. Лишний код - лишние баги и лишний головняк в будущем. Тем более когда это реальное пятое колесо у автомобиля.
-
Все дуже просто: якщо конфіг лежить в базі, його просто є сенс кешувати, а інвалідація кешу - під час зміни конфігу у базі. І всьо, робиться якийсь компонент, в якому це діло реалізоване, і до нього звертається просто потім, не думаючи над тим, звідки дані - з кешу, чи з бази. У мене так реалізовано (правда, компонент там чужий, але можна і самому зробити).
https://github.com/phemellc/yii2-settings (https://github.com/phemellc/yii2-settings) Ну власне це компонент, але він під фреймворк, але по суті, там нічого складного немає.
-
А потом окажется что ты например на диск D решил писать, а на очередной машине его просто не будет.
мы все же о разном говорим.
имеется фреймворк со своей структурой (ее, кстати, можно и даже желательно по-своему изменить)
там куча папок, файлов как системных, так и каждого конкретного приложения.
какой диск D в интеренете?! мы о разных вещах говорим.
упрощая, речь идет о достаточно рядовом по размеру и структуре массиве данных, который надо считать в начале работы скрипта. (при этом всегда читаются еще стандартно файлы конфигурации - системы, авторизации. автозагрузки, конф. БД, и т.д. .. потом наступает очередь библиотек, хелперов, моделей, представлений... и тд. )
ребяты, вы шо, не знаете об этом?! ;o
-
А потом окажется что ты например на диск D решил писать, а на очередной машине его просто не будет.
мы все же о разном говорим.
имеется фреймворк со своей структурой (ее, кстати, можно и даже желательно по-своему изменить)
там куча папок, файлов как системных, так и каждого конкретного приложения.
какой диск D в интеренете?! мы о разных вещах говорим.
упрощая, речь идет о достаточно рядовом по размеру и структуре массиве данных, который надо считать в начале работы скрипта. (при этом всегда читаются еще стандартно файлы конфигурации - системы, авторизации. автозагрузки, конф. БД, и т.д. .. потом наступает очередь библиотек, хелперов, моделей, представлений... и тд. )
ребяты, вы шо, не знаете об этом?! ;o
решение с кєшированием настроек уже дали выше
все остальное - велосипед на семи колесах, не усложняй себе жизнь. если интерес чисто академический - можешь баловаться :)
-
А потом окажется что ты например на диск D решил писать, а на очередной машине его просто не будет.
мы все же о разном говорим.
имеется фреймворк со своей структурой (ее, кстати, можно и даже желательно по-своему изменить)
там куча папок, файлов как системных, так и каждого конкретного приложения.
какой диск D в интеренете?! мы о разных вещах говорим.
упрощая, речь идет о достаточно рядовом по размеру и структуре массиве данных, который надо считать в начале работы скрипта. (при этом всегда читаются еще стандартно файлы конфигурации - системы, авторизации. автозагрузки, конф. БД, и т.д. .. потом наступает очередь библиотек, хелперов, моделей, представлений... и тд. )
ребяты, вы шо, не знаете об этом?! ;o
решение с кєшированием настроек уже дали выше
все остальное - велосипед на семи колесах, не усложняй себе жизнь. если интерес чисто академический - можешь баловаться :)
мы просто друг друга не поняли :(
мне надо просто небольшое усовершенствование в уже работающей не первый год системе - программно написать конфиг в том виде, к котором я написал бы его в редакторе. И все.
а по поводу "усложнений жизни"...
знаешь, сколько времени мне надо для создания удобной формы для совокупности нескольких таблиц?
Примерно: кол-во полей в этом наборе таблиц х 4-10 сек .
Все.
И ни одной строки не пишу. Автоматом создает. Надо лишь в др. форме пощелкать по кнопкам.
-
А потом окажется что ты например на диск D решил писать, а на очередной машине его просто не будет.
мы все же о разном говорим.
имеется фреймворк со своей структурой (ее, кстати, можно и даже желательно по-своему изменить)
там куча папок, файлов как системных, так и каждого конкретного приложения.
какой диск D в интеренете?! мы о разных вещах говорим.
упрощая, речь идет о достаточно рядовом по размеру и структуре массиве данных, который надо считать в начале работы скрипта. (при этом всегда читаются еще стандартно файлы конфигурации - системы, авторизации. автозагрузки, конф. БД, и т.д. .. потом наступает очередь библиотек, хелперов, моделей, представлений... и тд. )
ребяты, вы шо, не знаете об этом?! ;o
Я просто насмотрелся на чудаков, которые пытались оптимизировать то, что и так правильно работало - видел немало и подследствий оных оптимизаций тоже. :) Я потому про D и написал - и такие герои тоже попадаются. Рад что у тебя по крайней мере не локальный диск в дело идет.
Народ же творит что ни попадя порой... Ладно если для себя, а вот когда кастомеру такое всучивают..... Был например случай когда чел отвечающий за часть проекта вставил в код посылать ему прямо на почту дебаг при проблемах, почтовый адрес украинского оутсорса. Код ушел в дойч банк если я правильно помню, хорошо у них на их внутренних тестах это открылось, а не в рабочем состоянии. И хорошо что это был дойч банк, а не амерская CIA (Central Intelligence Agency) которая тоже этот продукт юзала.
-
А потом окажется что ты например на диск D решил писать, а на очередной машине его просто не будет.
мы все же о разном говорим.
имеется фреймворк со своей структурой (ее, кстати, можно и даже желательно по-своему изменить)
там куча папок, файлов как системных, так и каждого конкретного приложения.
какой диск D в интеренете?! мы о разных вещах говорим.
упрощая, речь идет о достаточно рядовом по размеру и структуре массиве данных, который надо считать в начале работы скрипта. (при этом всегда читаются еще стандартно файлы конфигурации - системы, авторизации. автозагрузки, конф. БД, и т.д. .. потом наступает очередь библиотек, хелперов, моделей, представлений... и тд. )
ребяты, вы шо, не знаете об этом?! ;o
Я просто насмотрелся на чудаков, которые пытались оптимизировать то, что и так правильно работало - видел немало и подследствий оных оптимизаций тоже. :) Я потому про D и написал - и такие герои тоже попадаются. Рад что у тебя по крайней мере не локальный диск в дело идет.
Народ же творит что ни попадя порой... Ладно если для себя, а вот когда кастомеру такое всучивают..... Был например случай когда чел отвечающий за часть проекта вставил в код посылать ему прямо на почту дебаг при проблемах, почтовый адрес украинского оутсорса. Код ушел в дойч банк если я правильно помню, хорошо у них на их внутренних тестах это открылось, а не в рабочем состоянии. И хорошо что это был дойч банк, а не амерская CIA (Central Intelligence Agency) которая тоже этот продукт юзала.
;)
не, опр. опыт у меня имеется. к сотням буржуйских сайтов успел приложиться, но это в прошлом.
тяжело без академ. образования, причем когда начинаешь заниматься этим в 40+ лет. А когда позади почти четверть века такой практики, то на особенно новое не тянет потому, что уже мозги не те.
-
Дуже цікавий велосипед, мати базу і ще щось постійно вичитувати з інклудів.
Ні, звісно хазяін-барін, але вимагати під кожну забаганку ще й готовий механізм то вже занадто.
Якщо це робиться разово, то руками і так не складно, а якщо то в майбутньому інклюді буде
часто оновлюватись, то нафіг таке тормознуте щастя.
-
Дуже цікавий велосипед, мати базу і ще щось постійно вичитувати з інклудів.
Ні, звісно хазяін-барін, але вимагати під кожну забаганку ще й готовий механізм то вже занадто.
Якщо це робиться разово, то руками і так не складно, а якщо то в майбутньому інклюді буде
часто оновлюватись, то нафіг таке тормознуте щастя.
хм..
при всем совершенстве механизмов бд она практически не несет информации о том, каким образом информация будет использовацца.
-
Дуже цікавий велосипед, мати базу і ще щось постійно вичитувати з інклудів.
Ні, звісно хазяін-барін, але вимагати під кожну забаганку ще й готовий механізм то вже занадто.
Якщо це робиться разово, то руками і так не складно, а якщо то в майбутньому інклюді буде
часто оновлюватись, то нафіг таке тормознуте щастя.
хм..
при всем совершенстве механизмов бд она практически не несет информации о том, каким образом информация будет использовацца.
Никто не мешает создавать по ходу пьесы свои таблицы с шаблонами и прописывать там всё что душа пожелает.
Ничем от инклудов не будет отличаться, но ковырять пальчиками на запись файловую систему вручную не нужно.
И если эти шаблоны нужно гибко и часто менять, то самое оно.
-
Дуже цікавий велосипед, мати базу і ще щось постійно вичитувати з інклудів.
Ні, звісно хазяін-барін, але вимагати під кожну забаганку ще й готовий механізм то вже занадто.
Якщо це робиться разово, то руками і так не складно, а якщо то в майбутньому інклюді буде
часто оновлюватись, то нафіг таке тормознуте щастя.
хм..
при всем совершенстве механизмов бд она практически не несет информации о том, каким образом информация будет использовацца.
Никто не мешает создавать по ходу пьесы свои таблицы с шаблонами и прописывать там всё что душа пожелает.
Ничем от инклудов не будет отличаться, но ковырять пальчиками на запись файловую систему вручную не нужно.
И если эти шаблоны нужно гибко и часто менять, то самое оно.
я сначала примерно так и делал. показалось, что негибко.
а если бояться перезаписать тобой же созданный файл при всех мерах предосторожности, то чего тогда не бояться?
-
так делают, но обычно кешируют не на диск, а в что-нибудь в памяти типа memcached или redis. Но как сказали, с оптимизацией нужно осторожно, т.к. сразу нужен механизм инвалидации кеша ну и десериализация на PHP может стоить дороже чем запрос к базе данных :)
-
(https://blog.toggl.com/wp-content/uploads/2017/02/7-circles-of-developer-hell-toggl-infographic-02.jpg)
-
навантаження на базу завжди знімалося кешем (у пам'яті або файловим)
які ще в біса інклуди?!
-
хм..
при всем совершенстве механизмов бд она практически не несет информации о том, каким образом информация будет использовацца.
Никто не мешает создавать по ходу пьесы свои таблицы с шаблонами и прописывать там всё что душа пожелает.
Ничем от инклудов не будет отличаться, но ковырять пальчиками на запись файловую систему вручную не нужно.
И если эти шаблоны нужно гибко и часто менять, то самое оно.
я сначала примерно так и делал. показалось, что негибко.
а если бояться перезаписать тобой же созданный файл при всех мерах предосторожности, то чего тогда не бояться?
Дело не в страхе, он тут вообще ни при чем, а в ресурсоемкости операций.
-
навантаження на базу завжди знімалося кешем (у пам'яті або файловим)
які ще в біса інклуди?!
не в самой нагрузке дело (хотя допускаю, что не очень ясно выразился сначала), а в способе доступа к метаинформации, которая после завершения разработки обновляется очень редко. Ее можно добывать либо запросом к БД, либо чтением имеющейся переменной, о которой идет речь. Никаких критичных требований к памяти и проч. нет. По сравнению с размером других инклудов и прочих загружаемых файлов в том же сеансе размер этого мизерный, но работу по программированию облегчает значительно. Например, размеры функций контроллера стали в 3-4 раза меньше, их легче понимать.
блин, я спрашиваю про одно, а практически все пытаются дать ответ на совсем другой вопрос, не понимая до конца сути и уговаривают ничего этого не делать. Да я делаю это давно, только вручную, и все прекрасно работает.
спасибо.
-
Никто не мешает создавать по ходу пьесы свои таблицы с шаблонами и прописывать там всё что душа пожелает.
Ничем от инклудов не будет отличаться, но ковырять пальчиками на запись файловую систему вручную не нужно.
И если эти шаблоны нужно гибко и часто менять, то самое оно.
я сначала примерно так и делал. показалось, что негибко.
а если бояться перезаписать тобой же созданный файл при всех мерах предосторожности, то чего тогда не бояться?
Дело не в страхе, он тут вообще ни при чем, а в ресурсоемкости операций.
о какой ресурсоемкости может идти речь, когда речь идет, например, об однократной перезаписи файла после добавления к БД новой таблицы? :facepalm1:
-
подивись як це зроблено наприклад в ZendFramework 2/3
там є конфіг-файли
-
ну, вот -практически все.
нарисовал малюсенькую рекурсивную функцию. сейчас еще для удобочтения добавлю табуляцию х уровень вложенности массива, запись в файл с резервным копированием, и фсё.
офигенный пожиратель ресурсов :K
-
ну, вот -практически все.
нарисовал малюсенькую рекурсивную функцию. сейчас еще для удобочтения добавлю табуляцию х уровень вложенности массива, запись в файл с резервным копированием, и фсё.
офигенный пожиратель ресурсов :K
опыта лет через 5 ты согласишься с теми, кто писал что ты не тем занимаешься :) А может и раньше.
-
ну, вот -практически все.
нарисовал малюсенькую рекурсивную функцию. сейчас еще для удобочтения добавлю табуляцию х уровень вложенности массива, запись в файл с резервным копированием, и фсё.
офигенный пожиратель ресурсов :K
опыта лет через 5 ты согласишься с теми, кто писал что ты не тем занимаешься :) А может и раньше.
выше я об опыте писал. Не обольщаюсь, но уверен, что некоторые советы даны теми, ктот родился на свет в пределах этого опыта.
-
и еще
Alexey Checkin3, не в обиду и не в Ваш адрес, но стремление давать советы, не относящиеся к самой сути вопроса, но стремящиеся только к глобальным обобщениям, тоже говорят о качестве и размере опыта имхо...
-
ну, вот -практически все.
нарисовал малюсенькую рекурсивную функцию. сейчас еще для удобочтения добавлю табуляцию х уровень вложенности массива, запись в файл с резервным копированием, и фсё.
офигенный пожиратель ресурсов :K
опыта лет через 5 ты согласишься с теми, кто писал что ты не тем занимаешься :) А может и раньше.
выше я об опыте писал. Не обольщаюсь, но уверен, что некоторые советы даны теми, ктот родился на свет в пределах этого опыта.
просто обычно все должно быть максимально просто, дабы легко разобраться в последствии в том числе другому челу. У тебя уже есть база, вот там стоило и хранить. Исключений в таком случае обычно мало (типа требования заказчика). Никаких проблем при хранении этого твоего добра в базе - не возникало, кроме мифической дополнительной нагрузки на базу :D
Ладно короче, по второму кругу идем, бросаю :)
-
и еще
Alexey Checkin3, не в обиду и не в Ваш адрес, но стремление давать советы, не относящиеся к самой сути вопроса, но стремящиеся только к глобальным обобщениям, тоже говорят о качестве и размере опыта имхо...
вот именно, опыт позволяет видеть дальше - понимать что будет через год например. А что касается совета по сути - я дал самым первым постом, если ты глянешь на первую страницу. Самый первый пост после твоего начального - я как раз и написал в каком файле хранить и как проще сделать :).
-
и еще
Alexey Checkin3, не в обиду и не в Ваш адрес, но стремление давать советы, не относящиеся к самой сути вопроса, но стремящиеся только к глобальным обобщениям, тоже говорят о качестве и размере опыта имхо...
Честно говоря, как-то чему-то вас учить желаение уже пропадает, вы же лучше знаете, да.
Просто представьте, что у вас веб сервер с вашим PHP кодом перестал справлятся с нагрузкой и потребовался еще один сервер (или 101), что произойдет?
-
и еще
Alexey Checkin3, не в обиду и не в Ваш адрес, но стремление давать советы, не относящиеся к самой сути вопроса, но стремящиеся только к глобальным обобщениям, тоже говорят о качестве и размере опыта имхо...
Честно говоря, как-то чему-то вас учить желаение уже пропадает, вы же лучше знаете, да.
Просто представьте, что у вас веб сервер с вашим PHP кодом перестал справлятся с нагрузкой и потребовался еще один сервер (или 101), что произойдет?
хм.. а если сервер перестал справляться и без "моего кода", то что произойдет?
-
Просто представьте...
... и тут замоячило слово "масштабируемость". :)
-
и еще
Alexey Checkin3, не в обиду и не в Ваш адрес, но стремление давать советы, не относящиеся к самой сути вопроса, но стремящиеся только к глобальным обобщениям, тоже говорят о качестве и размере опыта имхо...
Честно говоря, как-то чему-то вас учить желаение уже пропадает, вы же лучше знаете, да.
Просто представьте, что у вас веб сервер с вашим PHP кодом перестал справлятся с нагрузкой и потребовался еще один сервер (или 101), что произойдет?
хм.. а если сервер перестал справляться и без "моего кода", то что произойдет?
попробуйте сами понять чем эти ситуации различаются.
-
Честно говоря, как-то чему-то вас учить желаение уже пропадает, вы же лучше знаете, да.
Просто представьте, что у вас веб сервер с вашим PHP кодом перестал справлятся с нагрузкой и потребовался еще один сервер (или 101), что произойдет?
хм.. а если сервер перестал справляться и без "моего кода", то что произойдет?
попробуйте сами понять чем эти ситуации различаются.
ничем, я думаю
-
хм.. а если сервер перестал справляться и без "моего кода", то что произойдет?
попробуйте сами понять чем эти ситуации различаются.
ничем, я думаю
ОК, я попробую объяснить, хотя выше ключевое слово уже назвали :)
Вообще довольно регулярно вижу, что программисты не верят в свои проекты, не задаются вопросом "а что будет если мой проект станет популярным?" Есть ли план что делать, если нагрузка будет резко расти? Пусть сегодня это проект на PHP+MySQL, но принимая то или иное техническое решение всегда полезно задаваться этим вопросом и держать план реагирования на рост под рукой.
Предположим имеем ваш PHP код и сервер базы данных на одном сервере, ну и при модификации базы данных скешировали в файл что-то там. Все работает замечательно.
Но тут вы получаете рост нагрузки. Что делаем первым делом? Логично разнести приложение и базу данных по разным серверам. База данных пыхтит отдельно, кеш с админкой на одном web сервере.
Все пока работает, но нагрузка растет и видно, что PHP приложение не справляется, логично что сделать? Правильно, запускаем еще один web сервер. Уже возникает проблема, файл к кешем создается на одном веб сервере, с админкой, а нужен еще и на втором. Ну вроде не страшно, скопировали файл и живем дальше. Стало немножко неудобно копировать каждый раз после модификации базы данных, но пережить можно.
Нагрузка еще выросла, вы запустили 10 серверов. Копировать файл руками вам надоело и вы стали его при модификации автоматически пихать на сервера. Пришлось немного написать кода, но все ведь работает!
Тут выяснилось, что вы сделали супер сервис и он нужен всем! Нагрузка выросла сильно и вы запустили 100 инстансов веб сервера. С процедурой копирования файла начались сложности, выяснилось, что не все 112 серверов работают одновременно, кто-то перегружается, а кто-то сломался. Выяснилось, что push работает не очень здорово сам по себе, нужно еще делать запрос конфигурации из какого-то центрального хранилища при старте инстансов и еще как-то это совместить с процедурой деплоя свежих версий приложения.
Фак.
p.s. и тут начинает дымить сервер базы данных и вам требуется кешировать не десяток полей, а немного больше....
-
попробуйте сами понять чем эти ситуации различаются.
ничем, я думаю
ОК, я попробую объяснить, хотя выше ключевое слово уже назвали :)
Вообще довольно регулярно вижу, что программисты не верят в свои проекты, не задаются вопросом "а что будет если мой проект станет популярным?" Есть ли план что делать, если нагрузка будет резко расти? Пусть сегодня это проект на PHP+MySQL, но принимая то или иное техническое решение всегда полезно задаваться этим вопросом и держать план реагирования на рост под рукой.
Предположим имеем ваш PHP код и сервер базы данных на одном сервере, ну и при модификации базы данных скешировали в файл что-то там. Все работает замечательно.
Но тут вы получаете рост нагрузки. Что делаем первым делом? Логично разнести приложение и базу данных по разным серверам. База данных пыхтит отдельно, кеш с админкой на одном web сервере.
Все пока работает, но нагрузка растет и видно, что PHP приложение не справляется, логично что сделать? Правильно, запускаем еще один web сервер. Уже возникает проблема, файл к кешем создается на одном веб сервере, с админкой, а нужен еще и на втором. Ну вроде не страшно, скопировали файл и живем дальше. Стало немножко неудобно копировать каждый раз после модификации базы данных, но пережить можно.
Нагрузка еще выросла, вы запустили 10 серверов. Копировать файл руками вам надоело и вы стали его при модификации автоматически пихать на сервера. Пришлось немного написать кода, но все ведь работает!
Тут выяснилось, что вы сделали супер сервис и он нужен всем! Нагрузка выросла сильно и вы запустили 100 инстансов веб сервера. С процедурой копирования файла начались сложности, выяснилось, что не все 112 серверов работают одновременно, кто-то перегружается, а кто-то сломался. Выяснилось, что push работает не очень здорово сам по себе, нужно еще делать запрос конфигурации из какого-то центрального хранилища при старте инстансов и еще как-то это совместить с процедурой деплоя свежих версий приложения.
Фак.
спасибо за информацию. интересно.
одно но - всегда надо быть реалистом и решать задачи, исходя из ВОЗМОЖНЫХ реалий.
или лучше на всякий случай перейти на oracle заранее?
-
спасибо за информацию. интересно.
одно но - всегда надо быть реалистом и решать задачи, исходя из ВОЗМОЖНЫХ реалий.
или лучше на всякий случай перейти на oracle заранее?
Вы считаете успех вашего проекта невозможным? Так зачем им заниматься?
Oracle - не панацея, он ляжет под нагрузкой как и все остальные, возможно чуть позже, но и дороже.
Вы спросили как сделать лучше, вам и попытались объяснить как лучше кешировать данные и какие проблемы могут вылезти из тривиального решения.
Конкретное техническое решение конечно же за вами, вы знаете свою специфику, а я не хочу в нее вникать :)
Хорошим вариантом (имхо) является redis.
-
Вы считаете успех вашего проекта невозможным? Так зачем им заниматься?
я просто знаю, что даже если проекту и суждено стать самым лучшим в мире по своей тематике, то посещаемость вряд ли когда -то достигнет 20К/день
-
(http://lurkmore.so/images/e/e0/PHPSpotting.png)
-
Если ваш проект станет на столько популярным у вас будут ресурсы решать возникающие задачи, проектов которые реально могут перерасти возможности обычного PostgreSQL на максимально заряженном серваке от обычного вендора аля SuperMicro реально немного.
-
Засіб
Прекрасно можно на PHP/Hack писать большие проекты с красивым кодом и гавно кода на Python, Ruby, JS
написано тож не мало.
-
опыта лет через 5 ты согласишься с теми, кто писал что ты не тем занимаешься :) А может и раньше.
выше я об опыте писал. Не обольщаюсь, но уверен, что некоторые советы даны теми, ктот родился на свет в пределах этого опыта.
просто обычно все должно быть максимально просто, дабы легко разобраться в последствии в том числе другому челу. У тебя уже есть база, вот там стоило и хранить. Исключений в таком случае обычно мало (типа требования заказчика). Никаких проблем при хранении этого твоего добра в базе - не возникало, кроме мифической дополнительной нагрузки на базу :D
Ладно короче, по второму кругу идем, бросаю :)
Чечкин, Вы правы. В том, что надо все держать в базе. ПризнаЮ.
как выше упомянул, это я и делал до момента, когда решил добиться бОльшей универсальности. без лишних передач переменных в функции, присваивания значений одного другому, и т.д.
в фреймворке это никак не выходило, хотя облазил соотв. обсуждения (но, может, и проглядел что-то, допускаю).
нужен был, фактически, аналог константы, типа определенной с помощью define('ABC', 'la-ala.....').
и только сейчас, решив еще раз подумать над рекомендациями, допер сделать в конструкторе контроллера простое, как колумбово яйцо: define ('MYFUCKUNGDATA', $this->MCommon->ExtractMyFuckingDat aFomMySQL());
фсё.
теперь могу обращаться к этому делу, откуда угодно - в контроллере, модели, представлении, и т.д. без дополнительных операций.
спасибо.