phpDoc позволяет тебе генерировать доки по твоим классам - используй их.
Нравятся интерфейсы - опиши все паблик методы интерфейсом, никто не мешает.
В шапке классе в комментарии перечисли все имеющиеся в классе функции
первый вариант мне больше всего нравится - не плодятся ненужные интерфейсы + phpDoc полезен не только для генерации документации но и для подсказок ide, при разборе старого кода и тд - сплошные плюсы
радостно, что работает свой мозг, а не тупо идет по течению "моды". Для своих задач свои инструменты, есть приложения, которые я пишу на функциональщине, есть, которые я пишу в ООП-стиле. Не зацикливайся, со временем увидишь, что где лучше использовать
caballero, в среднем в России крупными сайтами занимаются команды до 10 человек программистов (яндекс не в счет). Насчет интернет магазинов - это не домашние странички, а готовые движки, например ShopScript ... приходится с ним сейчас работать, не так он отвратно написан, как я сначала думал
если по первому из составного ключа - не надо. А вообще ответ на такой вопрос занимает куда меньше времени, если прогнать типичный запрос с индексом и без него
я о том, что в той структуре на каждый тип идет своя таблица. в Их структуре сейчас 2 типа - строки и числа, как только этих типов будет больше - таблиц тоже будет больше. Если по каким-то причинам кому-то удобнее использовать юнионы - пусть использует, мне ближе 1 джойн и выбор, на какое поле смотреть. (Добавление)
Цитата:
это характеристика formats с текстовым значением
для разных товаров разное значение
что-то не догоняю
Это у вас текст, а у нас каждый поддерживаемый формат отдельно что бы по ним можно было выставить фильтр. Есть свойства-перечисления (как в примере), есть свойства - диапазоны (например, для каких возрастов подходит игрушка 4 - 8, а в фильтре можно спросить возраст ребенка и 6-тилетним детям показывать игрушки, у которых свойство возраст в нужном диапазоне ... но можно все сделать строками, я не спорю)
Да и инты в строки пихать можно, кто ж спорит, но это разные типы, с разным отображением
Цитата:
а это как? что у товара может такого быть например?
Это например "Форматы воспроизведения аудио" AAC, HE-AAC, MP3 (от 8 до 320 кбит/с), MP3 VBR, Apple Lossless, AIFF, WAV
Когда у одного свойства есть заранее заложенные варианты значений и можно выбрать либо одно значение из этого заранее заложенного списка, либо несколько
Привет. Попробую ответить хотя бы на часть твоих вопросов
Цитата:
начиная с какой цифры "одновременного" посещения к примеру главной страницы можно назвать проект highload-овым? Хотя бы приблизительно.
Это очень расплывчатое понятие, на равне с "говнокод", примерно. У каждого программсита своя оценка. Сам подумай, .html страничка, лежащая на народе может отдаваться при нагрузке в сотни, если не тысячи запросов в секунду, можно ли считать ее highload-овым проектом? а если к странице оформления заказа интернет-магазина идет такой же поток запросов?
Цитата:
Некоторые рекомендуют выделять несколько серверов для проекта, даже вычитал в книже(если ничего не напутал), что для хранений sessID выделяют отдельный сервер.
Это нужно делать ровно тогда, когда тебе это нужно (один сервер не справляется, нагрузка на хранилище сессий слишком велика и мешает выполнению остального кода) Странно, правда? А вот сделать так, что бы это было легко реализуемым, надо заранее.
Цитата:
Глаза разбежались, чего учить, для чего читать - не понятно. Более того недостаточно выучить, надо ещё умудриться спроектировать нагрузку очень грамотно.
Я не очень понимаю, что значит проектировать нагрузку? Есть четкие правила построения распределенных систем, надо их знать и программировать исходя из этих правил (если вы хотите в итоге иметь распределенную систему)
Цитата:
Вообщем хаос. - Что посоветуете делать со всем этим добром? Куда смотреть, чего читать, хотя бы для старта.
...
Цитата:
+ вопрос, есть ли к примеру сервисы, которые принимают всю ответственность по нагрузке на себя?
Я не понимаю, какую цель вы ставите перед собой. Если вы разработчик, который хочет научиться - советы будут одни, если же вам надо просто что бы работало - советы будут другими. В одной цитате вы интересуетесь как научиться, во второй вы спрашиваете, как отмазаться от изучения - это странно.
у нас вместо двух ваших таблиц feature_value_char и feature_value_int одна таблица feature_good_relation в которой есть:
good_id
feature_id
value_int
value_string
value_boolean
это позволяет получить нам значение свойств одним запросом. В твоей же реализации тебе надо сначала сделать запрос к features что бы получить тип свойства и понять, из какой таблицы брать связь. У нас же идет джойн одной и той же таблицы и в запросе ифами выбирается то или иное поле.