Сергей delphinpro, а для обучения развесистое IDE скорее вредно.
Ближе к блокноту - глубже понимание, что делаешь.
Иначе потом "С++ разработчик вышел из ВижуалСтудии и потерялся".
Dolarun, "что ты имел в своем виду - расскажешь папе с мамой" (с)
Если ты сам себе решил, что ты во что-то умеешь - как правило, первая же серьезная работа опровергает это заблуждение.
tgarl, более того - я уверен, что rsync-у на хрен не нужен OpenServer.
Вообще, проблему здесь вижу только в том, что бэкап веб-сайта на NTFS - заведомо плохая идея.
Что мешает посмотреть в браузере, что пришло с сервера? И заголовки, и содержимое.
Там, например, может быть нотис насчет того, что буфер сбрасывается, не начавшись.
Nikita, разумеется. Если заказчик хочет от вас только и исключительно поставленной задачи, ее стоит решать минимальным вмешательством, потому что любое другое чревато доминошками.
Вплоть до нулевого изменения таблиц и выборки-разбивки всего прямо в скрипте. При сотне статей за три года бутылочным горлышком это все равно, скорее всего, не станет.
3) Сделать полностью новую версию сайта, с нормальным хранением и обработкой данных. Не тратя уйму сил на попытки совместить "исторически слежавшееся" с нормальной архитектурой. За счет этого может оказаться даже быстрее рефакторинга.
Nikita, по "чисто информативным" статьям в основном и приходят новые посетители из поисковиков. Или, если поисковик видел эту статью по адресу с похеренным в процессе революции айдишником - получают 404 и не приходят.
ThunderCat, но не исключено, что оно в таком состоянии успешно работает лет десять. И те статьи давно проиндексированы и выносят сайт в топ по своей тематике. Переделаешь по-человечески - слетят ссылки... Благие намерения - дело непростое ;)
Nikita, без четкого понимания места этого добра на сайте я бы не рискнул давать какие бы то ни было советы.
Совет все переделать по-человечески, похоже, неприменим.
А вот косметические изменения требуют понимания работы с данными. Например, доступа к этим материалам и поиска по ним.
Возможно, вопрос можно решить добавлением одного поля `consultant_article_id` bigint(20) unsigned NULL
в первую таблицу, миграцией, создающей соответствующие записи, и обработчика, добавляющего такую запись при каждом добавлении во вторую таблицу.
А может, это создаст больше проблем, чем решит...
Nikita, "ситуация" только начала возникать, и ее стоит устранить в зародыше.
По той информации, которую вы дали, ни один телепат вам ничего конкретного не посоветует.
Ошибка проектирования. Различающиеся данные для статей можно вынести в отдельные таблицы. Разламывать же на две таблицы единую сущность - готовая ручка грабель.
Повышенная нагрузка - по сравнению с чем?
Сделайте этот скриптик-проверку по аяксу, не перегружайте его ненужными действиями - и если у вас не тысячи пользователей одновременно онлайн, вы эту "повышенную" даже не заметите.
ThunderCat, у CRM для мебельщиков и CRM для рекламщиков, разумеется, будут общие модули.
Технические - юзеры, доступ, настройки, почта, события и т.п.
Бухгалтерские - контакты, контрагенты, реквизиты, шаблоны документов...
А потом все-таки наступает тот решительный момент, когда общее - кончается. Ну не может быть единого модуля заказа у двух настолько отличающихся предприятий. Либо от него останется только название и интерфейс, а все остальное придется разделить. Либо придется ваять что-то настолько универсально-обобщенное, что тот код, который все равно будет разным, будет даже более громоздким, чем если бы обобщения не было вовсе.
Во всяком случае, моя практика привела к таким выводам. Возможно, если бы я работал не один, а студией, и еще несколько лет - мне бы открылся какой-то более правильный путь... пока, увы, я его даже не представляю.
В теории модули на "вкл/выкл" - это прекрасно, но мы говорим не об универсальной развесистой платформе, вокруг которой по документации пляшут разработчики-прикладники.
Мини-CRM же. Логика под каждого клиента, максимально близкая к его рабочим процессам. Одни и те же модули под разных клиентов будут разными, причем принципиально разными. И разрабатывать, и поддерживать их придется наособицу.
Другое дело - что ветвить проект под эти различия нет смысла просто потому, что эти ветки никогда не будут мержиться. Нечего в них объединять.
Ближе к блокноту - глубже понимание, что делаешь.
Иначе потом "С++ разработчик вышел из ВижуалСтудии и потерялся".