Что за расширения такие в общем и на примере postgre (если знаете)?
Например, имеется куча скалярных и табличных функций, не описанных стандартом. Это - расширение языка.
Ну или использование PostGIS. Или Foreign Data Wrappers.
И про "схема взаимодействия хранимых объектов" - что имеется ввиду?
Например, триггеры в PostgreSQL строятся совсем не так, как, скажем, в SQL Server.
Накидывая пункты в список, расшифровывающий указанное понятие, главное - вовремя остановиться.
По-моему, это, как минимум:
1. Знать основы SQL - в рамках последнего стандарта.
2. Знать особенности реализации и отклонения от стандарта в данной СУБД.
3. Знать основные расширения СУБД.
4. Знать идеологию и архитектуру СУБД (метаданные, система прав, схема взаимодействия хранимых объектов и пр.).
5. Знать основы оптимизации данной СУБД. Как СУБД в целом, так и отдельного запроса.
6. Знать средства резервного копирования и восстановления.
7. Для СУБД, поддерживающих распределённую работу - знать основы её организации.
Причём всё это надо знать на практике - то есть "делал руками, задачи были решены, в ходе решения проблем не возникло".
Всё описанное очень похоже на мастер-мастер репликацию.
Но подобный режим неминуемо будет создавать конфликты (одна и та же запись по-разному изменена на двух устройствах), требующие ручного "улаживания". Репликация же будет тупо херить более старые изменения. MySQL не имеет средств, позволяющих полноценно реализовать такой режим работы с правильным "разведением" конфликтов в автоматическом режиме. Однако если Вы будет избегать возникновения такого рода конфликтов, не вижу особой проблемы.
Судя по "А я типа вообще ничего не делаю" - ты даже не озаботился элементарно сравнить статистику WAN-интерфейса своего роутера со статистикой сетевой карты компьютера и посмотреть, твой это трафик или нет.
"Смартфон пока отключил от Wi-Fi." - а комп по WiFi или по меди?
rinaz22, не, вот что толку с твоих приблизительных описаний, а? Дай ТОЧНЫЙ результат для ИМЕННО ПОКАЗАННЫХ исходных данных. Да ещё и с подробными пояснениями, как именно он получен из этих исходных.
таблица в которую каждый день записывается общее кол-во просмотров конкретной страницы
А при отсутствии посещений ноль пишется? Возможно ли вообще отсутствие данных для какой-то страницы за какую-то дату?
И есть ли где-то в отдельной таблице список всех страниц?
как связать сразу несколько записей к одному пользователю при получении?
Зависит от конкретного вида данных и требуемого результата. Добавьте в вопрос пример - исходные данные как CREATE TABLE + INSERT INTO (3-4 записи) и то, что хотите получить на выходе (либо вывод запроса, либо CREATE TABLE + INSERT INTO финальной структуры) для именно этих данных. Ну и не забудьте указать точную версию СУБД.
Есть такая штука как нормализация данных. И она требует, чтобы каждое значение хранилось в отдельной записи, вместе с указателем на то, что это за значение и к чему относится.
Например, сейчас достаточно модны всякоразные прокси и прочие випиэны - именно их адрес и будет получен вместо реального адреса посетителя. Ну кроме прозрачных проксей, которые куда как менее массовы.
Ну или технология NAT, которую используют практически все провайдеры и подавляющее большинство организаций - тут вместо реального адреса посетителя будет получен адрес внешнего интерфейса NAT-маршрутизатора. К слову, было время, когда через один внешний адрес могли выходит в Инет куда как более тысячи абонентов..
Так что лучше выбросите эту идею из головы. Совсем. Ну или сделайте, но оставьте эту статистику только для себя, и никому про её даже не рассказывайте. Ладно если просто засмеют, а если это человек, который принимает решения, и он это сделает на основании Вашего гадания на кофейной гуще?
Вот прям вспомнилось Хазановское "Я не помню названия песни, и не помню, кто написал музыку и слова, зато кто исполнял песню я тоже не помню.. но очень прошу её повторить!".
Например, имеется куча скалярных и табличных функций, не описанных стандартом. Это - расширение языка.
Ну или использование PostGIS. Или Foreign Data Wrappers.
Например, триггеры в PostgreSQL строятся совсем не так, как, скажем, в SQL Server.