Если мы вставляем обновления в туже таблицу где хранятся оригиналы, каждая запись будет иметь свой id и получается нужно 2 идентификатора, один записи, другой пользователя. И все связи нужно крепить на id пользователя.
Извините, но вы переходите к обсуждению того самого коня в вакууме. Изменение предметной области, причём изменение чуть ли не критичное, очевидно приведёт к полному пересмотру всей схемы. И уж точно к пересмотру того, что именно в таблице будет идентифицирующим признаком (как первичным, так и групповым). А вы пытаетесь всё то же сделать какими-то минорными изменениями.
historydev, вопрос совершенно непонятен. Идентификатор записи в рабочей таблице явно не будет являться идентификатором записи в таблице логов. Хотя скорее всего будет его компонентом.
historydev, как раз с точки производительности первый вариант ничем не проигрывает второму, если использовать партиционирование по полю актуальности. Правда, можно отловить проблем с других сторон, так что такие вещи нужно хорошо планировать.
А экономия места - при том, что дисковое пространство сейчас достаточно дешёвое,- почти бессмысленна. Можно вынести лог на отдельный диск, который, в отличие от дисков с данными, может быть и небыстрым. Ну и ничто не мешает периодически архивировать логи, благо жмутся они весьма неслабо.
lexchz, было бы неплохо увидеть структуру исходных таблиц и статистику данных в разрезе связывания. Потому как оптимизироваться точно есть куда. Например, pc2.product_id используется в критерии связывания для INNER JOIN, то есть в финальном наборе это гарантирует NOT NULL, что просто криком кричит о замене COUNT(pc2.product_id) на COUNT(*).
На уровне БД есть два стандартных решения.
Первое - это использование "мягкой" технологии, когда любое изменение выполняется путём создания новой записи с актуальным состоянием, а предыдущая помечается как неактуальная либо используется системный штамп времени.
Второе - это создание для каждой таблицы пакета триггеров, который пишет все изменения в журнал.
Оба способа обеспечивают полное журналирование ценой расхода дискового пространства. Первый удобнее при откатах, второй при формировании экшен-логов.
Как это реализуется и отображается во фронте - не скажу, ибо не использую.
Дмитрий, ну тогда будет один комплексный запрос с несколькими CTE. Нормальное вменяемое решение. Я не зря ну очень заострил внимание на том, что речь строго о показанном шаблоне.
И по скорости почти наверняка выиграешь солидно.
С чего бы плохо-то? Тут разве что читабельность может пострадать, особенно если запрос получится объёмный да многосоставный. Но если хорошо документировать и комментировать запрос да использовать вменяемые алиасы, так и вовсе тут ничего плохого.
For InnoDB, DATA_LENGTH is the approximate amount of space allocated for the clustered index, in bytes. Specifically, it is the clustered index size, in pages, multiplied by the InnoDB page size.
Ну не то чтобы совсем ерунда, но плюс-минус лапоть. Для обновления используем ANALYZE TABLE? при отсутствии конкурентов есть шанс получить точные данные.
Открой "Панель управления" -> "Устройства и принтеры". Именно панель управления, а не десятошное "Параметры" (выведи на экран через Темы - Значки рабочего стола, оно там и вообще полезно). Внизу будет блок "Устройства мультимедиа", где будут в т.ч. и найденные по сети смарт-ТВ. Ну и ПКМ - подключиться...
Само собой в настройках ТВ должны быть разрешены внешние подключения.
Я как-то вообще без проблем с ноута с десяткой подключаюсь к двум телевизорам (в гостиной и на кухне) со смарт-ТВ с дублированием экрана, после чего запускаю фильм... поскольку у меня у всех сеть по кабелю, проблем с пропускной способностью нет. Без дополнительного софта...
bouslayeff, ну так нужно мостовое соединение подключать не к физическому, а к виртуальному VPN-интерфейсу хост-машины (если таковой формируется). А если VPN-адаптера нет, и VPN просто прозрачно перенаправляет/маршрутизирует, то виртуальная машина мостом подключается к соотв. физическому интерфейсу и самостоятельно поднимает свой VPN, через который ходит куда и как нужно безотносительно к VPN хоста.
Извините, но вы переходите к обсуждению того самого коня в вакууме. Изменение предметной области, причём изменение чуть ли не критичное, очевидно приведёт к полному пересмотру всей схемы. И уж точно к пересмотру того, что именно в таблице будет идентифицирующим признаком (как первичным, так и групповым). А вы пытаетесь всё то же сделать какими-то минорными изменениями.