Просьба голосовать только людям имеющим опыт. Итак, у нас в офисе при проектировании новой системы возник спор. Нашли один выход чтоб не подраться - чтобы опытные товарищи тупо проголосавали и тем самым мы выяснили истину . Спор возник по следующим предложениям: "названия таблиц должны быть прописаны константами в своем файле, пример: users_tables.php, define(‘TABLE_USERS’,’mp_users’); .... В итоге мы получим набор файлов: файл с константами таблиц, файл с классами и функциями. И возможно файл с настройками конкретного модуля пример: users_settings.php." То есть на каждый "модуль" (по-русски функциональный блок), будет отдельный конфиг. Плюс конфиг системы. Исходные данные: Нужно разработать систему с относительно не большим функционалом. Наиболее близкое к теме - файловый архив. Подразумевается будут каталоги, рейтинги, пользователи, биллинги, возможно блоги ну и комменты естественно. Систему нужно сделать в кратчайшие сроки но качественно. Подразумевается что портал будет один. Дальнейшее развитие планируется и вероятнее всего будет. Возможно далее он будет пару раз клонирован. Мнения разделились следующим образом (несколько аргументов): 1. Все фреймверки пишутся так и каждый модуль это должен быть не зависимой единицей, поэтому все конфиги в разщных файлах. Проще переносить систему/части системы. При этом даже если переносить "проще" части системы связаны между собой... и пернос вообще мало вероятен... скорее его не будет... так же как и правки модулей. 2. Нам нужна не гибкая, а быстрая и надежная система поэтому все конфиги вынесим в один файл. Пример: на странице 5 функциональных блоков, к странице 2 000 обращений. Соответственно будет сделано 10 000 инклудов по 3 строцки. В то время как все 50 строчек конфига можно просто записать в один файл. Проще редактировать - все в одном разделив их по модулям, проще использовать, они всегда есть в наличии. Вот проголосуйте, пожалуйста, кто как считает. Если не сложно прокомментируйте свой вариант ответа. Угадайте за что в этом тексте голосовал я . Edited by Administrator
Много букав не асилил, смысла нет. Нормально вопрос задал бы. Если ресурс будет развиваться то надо делать модульную систему с конфигами для каждого модуля, а если всё жёстко и не будет развиваться то можно писать даже в код или юзать один конфиг
Съест немного памяти на каждый проход программы, но ослабит груз на дисковую подсистему. Трудно оценить на этапе проектирования приемущество или недостаток такого подхода. Зачем?! Я никуда не выношу названия таблиц куда-либо, они у меня в запросах прописаны. Я делаю префикс к таблицам. Его можно обозначит как константу и подставлять перед именем каждой таблицы. А если сделать на каждый модуль табличку в БД с конфигом (| conf_name | conf_value |) и грузить её в случае использования модуля?! В таком случае снизим ресурсоёмкость приложения по памяти, но увеличится груз на сервер БД. Однако сервер БД, в отличие от дисковой подсистемы, можно очень гибко настроить на максимальную производительность. Можно свалить все параметры в одну таблицу и выбирать параметры модуля соответствующим запросом, чтобы не выбирать всё. У меня принцип следующий - каждый модуль должен затребовать и получить от ядра именно те данные (параметры) которые ему нужны, а не грузить по несколько мегабайт ненужных данных. Соответственно ядро должно быть спроектировано соответствующим образом.
Administrator обиделся на слово "жестко" почистил мое сообщение. Можете устно переголосовать, учтем А файлов будет качаться много... Плохая идея. Мне не нравится.
так в чем разница, все имя таблицы в запросе или часть? чтобы писать константу+имя вместо константы? имена таблиц - это не мегабайты данных. зы у меня был случай, при переносе на другой хостинг потребовалось сменить маленькие буквы в именах таблиц на большие (или наоборот, не помню). у меня это заняло 5 сек - копипастом в ворд. ззы имхо тут путается вынос имен таблиц и конфиги модулей. Это разные вещи.
соотношения кол-ва конфигов должно быть оптимальным. лучше их объединять, но не до такой степени, чтоб в одном конфиге было 100 групп настроек. ямои предпочтения: конфигов должно быть не более 3х-5-ти подгрузка соответствующего конфига - автоматически т.е. зачем грузить все конфиги если мы используем на данном этапе только часть конфиг должен быть в XML (для более удобной визуализации конфига) XML- парсится системой единожды и превращается в ассоциативный массив (у меня XSLT), который сохраняется в виде пхп текста. хочу заметить единожды (после изменения изменении конфига) конфиг желательно кешировать в шаредмемори мой подход не обязательно должен быть удобным для других
Жесткой может быть системя прив\язанная например к железу специфическому. А тут простой сайт / портал / интернет магазин. формулировка некорректная. Файлов возможно будет качаться много но стильнаписания ситемы на это ни как не повлияет.
В каком смысле. Если 100 юзверей одновременно обновят страничку?! Так сто раз один и тот же файл подгрузится, а если их два (конфиг модуля и системы), то получим 200 инклудингов. Опять же сложно сказать, будут ли два маленьких файла грузиться быстрее файла заведомо больше чем эти вместе взятые. Просто хлопот больше. А по мне, так это самый правильный вариант.
Если б так взяли бы любую понравившуюся цмс и на базе ее подняли... так что я вновь с тобой не согласен
В прямом смысле. Предлагают тут некоторые... Сделать дофига инклудов (вариант 1), плюс ко всему прочему постоянно будут качаться большие файлы с сервера и на сервер... база будет MySQL, а я его не люблю сильно нагружать... больно уж он падкий при больших нагрузках.
Если хотим получить максимальное быстродействие, то я бы сделал так: Один конфиг для ядра системы - грузится всегда. Остальные конфиги по одному файлу на каждый модуль, грузятся по мере надобности.
если 100 раз подряд запросить один и тот же файл - ни одна приличная ОС не будет обращаться к диску боле 1 раза...
один общий конфиг, остальные конфигурационные параметры должны быть в самих модулях, без каких там либо дополнительных конфиг фаилов, потому что эти конфигурации индивидуальны для каждого модуля. оформите красиво в верху фаила модуля с комментами и всё будет в ажуре. А по поводу грузить дисковую подсистему и всё такое - ребята, давно пора юзать opcode кешеры (я без XCache уже вообще не работаю) - все фаилы лежат в памяти в виде опкода и грузяться моментом
Зависит от системы, если она планируется на один сервак то можно и в одном, если это продукт общего пользования который будет комплектоваться различными модулями в зависимости от пользователя то конечно отделить...
судя по комментам заскок не только в этом... так всегда бывает, когда не подкрепляешь свои слова результатами тестов...