Это конечно да, но ежедневный бекап по крону ситуацию несколько смягчит. Хотя конечно лучше приучать пользователей к прекрасному и журналируемые двиги здесь как нельзя кстати... :)
Радует что в этом списке присутствует такой зверь как Битрикс :)
Такого у меня точно не будет)))
Равно как и не будет сверхуниверсального движка с миллиардом модулей и функций, из которых каждый конкретный разработчик спользует отсилы 5%. Так что если бы у меня было свободное время то думаю за месяц я бы легко справился, а так скорее всего через месяц будет максимум бетта, а то и альфа :)
Вот с этим согласен. Совсем уж универсальности не будет. Черновое название двига "Принцип Парето" ;) По сути это основа идеологии движка....
Бывает :)
На самом деле я по сути привожу в порядок свои библиотеки которые я уже около семи лет как использую. И они использовались и в доргенах и в ГС-ах и в биллингах... (с небольшими вариациями).
очевидно что нетвинд считает что увеличение размеров базы увеличит количество обращений к винту.
Думаю это не так ибо данные то остаются те же... место идет на журналы и т.п.
опять же работа с журналами при записи а не при чтении....
Раньше говорили что пхп не для серьезных проектов, теперь что серьезные проекты на wvc не делают? :) На самом деле такие системы все равно работают под тем или иным фреймворком. Другое дело что его пишут как правило специально под проект, или очень сильно адаптируют существующий. Хочу чтобы мой двиг был пригоден для таких адаптаций. В любом случае такие вещи всегда пишутся в первую очередь для себя, а во вторую для других... Поэтому я изначально на этапе проектирования стараюсь заложить максимальные возможности роста, при этом оставив максимально "легкий" код.
Ну у меня лично пунктик на целостности данных.
У меня на обслуживании одна дефективная система - распределенная база на 300 пользователей на 60 подразделений. Синхронизация идет "оффлайн" с периодичностью в два часа-сутки-неделя.
Разработчик в принципе таких вещей как целостность данных не знает....
в общем банальная склейка дублей превращается в почти невыполнимую задачу.
Это только одна из сторон проблемы.
Система изначально писалась под задачи другого филиала (другой области) который по размерам как одно наше крупное подразделение... Человек использовал довольно приличный движок, но он был настолько туп, что пока я хорошо не разобрался в двиге я был уверен что это все дефекты двига :) При этом если бы в двиге некоторые фичи были бы по умолчанию, то мне бы жилось намного легче ибо не было бы зависимости от дибилов разработчиков.
(и не надо мне говорить что надо правильных подрядчиков надо выбирать - это решение на уровне министрества. и не надо мне говорить что надо правильную власть выбирать ;) сам знаю....)
Ну и плюс не стоит забывать что двиг УНИВЕРСАЛЬНЫЙ. И я почти наверняка буду под ним биллинги писать, а значит транзакции не помешают.
Список критериев со значениями. Пример:
ЧПУ - ДА
Скорость работы - СРЕДНЯЯ
Семантическая разметка - ДА
Удобный инструментарий для внутренней перелинковки - НЕТ
Умеет говорить пользователям из 87.250.238.0/24 "Здравствуй начальника!" - ДА
Сайт-мап хмл - ДА
Сайт-мап - хтмл - НЕТ
Пинг РСС - ДА
Спасибо, полезно. В реальной жизни правда будет не так, но общая картина ясна.
Ну вдруг кто-то на ней второй вконтакте сделает? :)
А если серьезно то нафиг не нужно.
Хочется при минимальном размере ядра дать максимальную защиту от дурака и простоту проектирования.
Трудно найти черную кошку.... ;)
Платон сказал в первую очередь про ТИЦ! Это значит ап ТИЦ будет раньше чем выдачи!
А если серьезно то из вопроса про санкции не ясно что вы хотите позиции получить а не ТИЦ.
можно сделать предположение, что фильтр снят, что-бы голову не морочили, но траста Вам не видать иначе Вас бы не приняли за линкоторговца которому важен ТИЦ :)
Да и то гипотиза не самая надежная...
Все остальное - словоблудие.
переходы с каталога.
Спасибо. Полезная ссылка.
Правда отсутствие InnoDB скорее не на скорость повлияет а на надежность :)
mendel добавил 03.02.2010 в 19:24
Агава это мазохизм.
мастерхост не знаю дела не имел...
Спасибо, попробую.
