madc0de, уж CRUD новостей-то - зачем Вам фреймворк?!
Это на "чистом" PHP пишется за сутки.
1. По уязвимостям и контролю качества front-end: тут
2. По списку работ по НОРМАЛЬНОЙ! разработке: тут (под схемой)
PS (это не плюс и не минус, просто озвучу для Вашего понимания): Более - я не смогу подсказать по Yii (и подобным), т.к. сам я или пишу на "чистом" PHP, или когда нужна админка/GUI заказчику - я работаю с Framework Joomla и, соответственно, CMS Joomla! (и там уже пишу приложения, модули, компоненты, плагины, шаблоны).
xDimus, обычно, все прямые линки - подчиняются какому-то правилу. А все переходные линки - присутствуют в "теле" каждой из связанных между собой страниц.
Леонид Рожнов, ну тут всё просто:
Любые ячейки любой одной или нескольких записей: A и B
1. Клиент 1 Сервер 1: A=1
2. Клиент 1 Сервер 2: A=A+20
3. Клиент 1 Сервер 1: B=B+10
4. Клиент 1 Сервер 2: B=5
5. Клиент 1 Сервер 1: B=A+B
Здесь видно, что значения переменных A и B не влияют друг на друга.
Поэтому транзакции 1 и 2 могут выполняться одновременно с 3 и 4.
А уже 5-ая - зависимая от результата предыдущих 4-ёх и может исполняться только после того, как будут выполнены все от 1 до 4.
Вот это - Вам нужно оптимизировать, чтобы иметь возможность обработки независимых данных в приоритетном режиме.
dllweb, ну если кратко про формы собственности (и подобные), тогда так:
1. Это отдельная таблица
2. Если планируется использование сразу нескольких полей справочника для одной записи:
У каждой записи свой коэффициент, кратный степени двойки. (1,2,4,8,16,32 и т.д.) При выборе нескольких параметров - коэффициенты складываются в сумму, образуя идентификатор набора из этого справочника.
3. Если планируется использование только одного поля из справочника, то указывается просто id конкретной записи из этого справочника.
Почему не alias?
Потому, что alias - это для человека и это огромный избыток данных для внутренних вычислений и индексации (для дальнейшей выборки и других операций с данными) БД в CPU сервера.
Обычно, для людей - это поле caption/text/description и т.д.
Для системы - это всегда id (или подобные целочисленные беззнаковые идентификаторы).
Леонид Рожнов, тогда синхронизируйте во время импорта локальную базу (клиентскую) с удалённой, удалённую в этот момент - блокируйте (ставьте на паузу) на обновление синхронизируемых данных.
После синхронизации локальной - пересчитывайте на клиенте все операции обновления на новые и сразу же отправляйте на удалённую (центральную) базу.
После успешной отправки и синхронизации на удалённой БД - снимайте блокировку на удалённой БД.
Т.е. нужно, чтобы был виртуальный пул транзакций на локальной БД, который потом приводится к реальной разнице между текущим состоянием этого пула и реальной удалённой БД и затем синхронизируется.
При ошибках (перекрывающихся и взаимоисключающих операциях, которые стали невозможны по причине изменения данных на удалённой системе другим клиентом) - нужно выводить диалоговое окно с сообщением невозможности осуществления операций.
