ThunderCat, но не исключено, что оно в таком состоянии успешно работает лет десять. И те статьи давно проиндексированы и выносят сайт в топ по своей тематике. Переделаешь по-человечески - слетят ссылки... Благие намерения - дело непростое ;)
Nikita, без четкого понимания места этого добра на сайте я бы не рискнул давать какие бы то ни было советы.
Совет все переделать по-человечески, похоже, неприменим.
А вот косметические изменения требуют понимания работы с данными. Например, доступа к этим материалам и поиска по ним.
Возможно, вопрос можно решить добавлением одного поля `consultant_article_id` bigint(20) unsigned NULL
в первую таблицу, миграцией, создающей соответствующие записи, и обработчика, добавляющего такую запись при каждом добавлении во вторую таблицу.
А может, это создаст больше проблем, чем решит...
Nikita, "ситуация" только начала возникать, и ее стоит устранить в зародыше.
По той информации, которую вы дали, ни один телепат вам ничего конкретного не посоветует.
Ошибка проектирования. Различающиеся данные для статей можно вынести в отдельные таблицы. Разламывать же на две таблицы единую сущность - готовая ручка грабель.
Повышенная нагрузка - по сравнению с чем?
Сделайте этот скриптик-проверку по аяксу, не перегружайте его ненужными действиями - и если у вас не тысячи пользователей одновременно онлайн, вы эту "повышенную" даже не заметите.
ThunderCat, у CRM для мебельщиков и CRM для рекламщиков, разумеется, будут общие модули.
Технические - юзеры, доступ, настройки, почта, события и т.п.
Бухгалтерские - контакты, контрагенты, реквизиты, шаблоны документов...
А потом все-таки наступает тот решительный момент, когда общее - кончается. Ну не может быть единого модуля заказа у двух настолько отличающихся предприятий. Либо от него останется только название и интерфейс, а все остальное придется разделить. Либо придется ваять что-то настолько универсально-обобщенное, что тот код, который все равно будет разным, будет даже более громоздким, чем если бы обобщения не было вовсе.
Во всяком случае, моя практика привела к таким выводам. Возможно, если бы я работал не один, а студией, и еще несколько лет - мне бы открылся какой-то более правильный путь... пока, увы, я его даже не представляю.
В теории модули на "вкл/выкл" - это прекрасно, но мы говорим не об универсальной развесистой платформе, вокруг которой по документации пляшут разработчики-прикладники.
Мини-CRM же. Логика под каждого клиента, максимально близкая к его рабочим процессам. Одни и те же модули под разных клиентов будут разными, причем принципиально разными. И разрабатывать, и поддерживать их придется наособицу.
Другое дело - что ветвить проект под эти различия нет смысла просто потому, что эти ветки никогда не будут мержиться. Нечего в них объединять.
И вынести доделки в модули, чтобы сайт каждого клиента можно было собрать с нуля одним скриптом с нужными параметрами. Если сайт однозначно определяется модулями - так же однозначно определятся и нужные ему миграции при необходимости обновления не только кода, но и базы.
(Включил коту лампу) Ну-ка, ну-ка, давайте послушаем. И как же это голанг работает "ускорителем" для пыха?..
Мой вопрос может показаться вам глупым или простым, но я не хочу неправильно учиться.
А правильно учиться вы точно хотите? Странные вопросы как бы намекают...
Впрочем, ладно. Вы хотите поучить Го? Так поучите Го, к чему вообще эти сорок коробов небылиц?
Сначала надо разбить на слова (хотя бы и тем же поиском пробелов), потом в них уже искать подстроку.
Либо от позиции подстроки в обе стороны искать пробел, определяя границы того слова, в котором она встретилась.
m000gg m000gg, и молча выполняет v[1] += x[1][0], когда v == { 0 }?
Или у вас после всей этой кашицы просто нет в матрице элементов, оканчивающихся тройкой?
mayton2019, мне надо было привести остальные пять case, в которых ничего подобного нет? Вы придираетесь к примеру, которым я иллюстрирую озвученную проблему. Switch ничем особенным от прочего кода не отличается, кроме вот такой вот засады по иллюзорности областей видимости. Скобки ее устраняют, совсем недорого и по написанию, и по прочтению.
