Сергей Еремин

Если данные не за одни сутки и нужно получить данные за весь период, то как-то так:

SELECT
  DATE(table.dattim) AS DD,
  HOUR(table.dattim) AS HH,
  AVG(table.value) AS AVG_VALUE
FROM table
GROUP BY DD, HH
ORDER BY DD, HH

Последние версии MySQL и MariaDB не дают подключать клиентов под root. Зайти под root можно только из клиента запущенного от sudo. Следовательно:

1. или запустить Workbench из под sudo (не вариант);
   
2. или создать в пользователя с правами на всё (эквивалентные админским, вход делаем sudo mysql -u root) и уже после коннектиться из workbench от имени этого пользователя.
   

Судя по принтскрину, в таблице для разных столбцов используются разные кодировки. Проблема может быть в этом. Не знаю, поможет это в твоем случае, но стоит попробовать:

Сделай дамп базы. Открой его в текстовом редакторе. Глазками посмотри что у тебя в тех полях которые идут умляутами и прочими квадратиками и вопросиками. Попробуй разобраться где какая кодировка образовалась и совпадает ли она с тем, что указано при создании таблиц и полей (вполне подходящий инструмент FAR Manager, в нем можно менять кодировки при просмотре и редактировании. Напиши скрипт, который унифицирует кодировки при создании таблиц и полей, а так же сделает перекодировки значений полей при их заполнении данными. Если данных в табличках не много -- все можно даже руками сделать в текстовом редакторе.

После залей этот исправленный дамп на сервер.

Не знаю насколько поможет совет (сам я PHP не практикую) но мне кажется оптимальнее использовать формирование дат на клиенте c помощью JS ... momentjs.com/docs Так проще сделать кросс-языковый вывод.

Все такие селекты за отдельные периоды собираешь юнионами... Все...

Не усложняйте себе жизнь. У вас есть данные. Вы знаете как вы с ними будете обращаться, как часто читать, как часто обновлять, по каким полям сортировать, как группировать... Вы знаете каких данных много, каких мало... Все что остается -- разбросать по разным таблицам и наладить связи.

Из того, что реально стоит забот: решить в каком месте стоит уступать стройности данных и выбрать дублирование в ущерб производительности. Но это лучше понять когда начнете реально нагружать свое творение и увидите, что, например, рекурсивные вопросы не так уж красивы и ради них стоит ввести еще одно поле. А какое -- с уровнем вложенности или обозначения корня вложений -- решите по ходу дела.

В БТИ очень строго. Там же сплошь и рядом персональные данные о собственниках, регистрации и пр. Слежка за обращениями сотрудников, алармы на частые запросы и пр. Соседка работала в БТИ, так она две недели подгадывала, чтоб посмотреть данные по моей квартире так, чтобы не вызвать лишних вопросов.

Если нужно что-то не связанное с персональными данными, то лучше искать альтернативные источники. Многое открыто. Например, Иван правильный ресурс посоветовал. Многое оттуда можно вытянуть.

Зависит от того какие и сколько запросов на чтение и запись будете строить.

Чего проще? Входишь в консоль SQlite и делаешь:
.tables
смотришь какие таблицы созданы в модели (там же бывают всякие:

class Meta:
        db_table="что-то"

и не факт, что схема наименования таблиц дефолтная). А когда уже знаешь имена таблиц делай им:
.dump ?TABLE?

www.sqlite.org/cli.html в помощь

Ответ не будет, пока не ясно какая нагрузка. Свой сервер -- дорогая игрушка (учите, что надо будет платить на юнит в стойке провайдера, порты, IP-шники, питание. Все это "постоянные издержки" которые стартапу всегда надо минимизировать. Когда проект будет в плюсе по "переменным издержкам", то уже можно смотреть как избавившись от некоторых из них, и переложившись в "постоянные издержки" сэкономить. Так что садитесь на виртуалки или комбинацию сервисов Amazon и вперед.

А как-нибудь иначе, например прям из брокерского терминала не проще брать котировки? Многие дают с радостью, только попроси.

Постучись в сообщество postgresql-истов.
https://www.facebook.com/groups/postgresql/
Они правда апологеты другой религи, но помогут.

P.S/ Имхо, можно руками. SQL-файл текстовый. Если там не очень наворочено с индексами и связями, то возможно достаточно типы переменных в таблицах поправить.

Без ТЗ сложно сказать. Мне кажется что функционал вполне стандартный и можно обойтись таблицами ПОЛЬЗОВАТЕЛЬ и ПУБЛИКАЦИЯ. Если в публикации есть ссылка на родительскую публикацию то это комментарий и дальше можно их этого строить хоть ленты хоть деревья. Еще, конечно, нужно таблицу ТЭГОВ иметь, но пока не ясно что из нее надо будет строить )может связанные массивы релевантности) то про ее структуру сложно сказать сто-то определенное. Для чего нужна таблица СПЕШАЛ (и связанные таблицы) вообще не понятно.

P.S. Кстати, а с помощью чего нарисована схема?