Сергей П

БД не гарантирует и не обеспечивает никакого конкретного порядка хранения данных. Извлекаются данные из БД также без определенного порядка, если вы не указываете сортировку в SQL-запросе явно.
Также не очень хорошая идея привязывать порядок слов в словаре к ключу. Так вы не сможете добавлять словарь между словами, ведь ожидается алфавитная сортировка. Просто не считайте ключевое поле упорядоченным и как-то влияющим на порядок, а слова сортируйте по алфавиту с помощью SQL-запросов. Ну и да, нужно сделать соответствующий индекс на этой таблице.
А вообще такие основы можно прочесть в любой книжке про базы данных.
Мой вам совет - начните с книги.

Транспонирование таблиц в SQL не предусмотрено в большинстве БД.
Если набор параметров динамический, то так не получится, потому что не ясно сколько получится столбцов в итоге, а динамически их делать нельзя.
Можно собрать JSON с атрибутами, но это тоже такое себе.
Обычно такое транспонирование делают в коде на бэке, а не в SQL.
Между тем вы не написали даже какая у вас БД и на чем делаете бэкенд.

На постгресе оптимально было бы сделать джойн, группировку, а при агрегации собирать массив key-value, или JSON, тогда у вас будет два столбца: id, params. Второй столбец будет содержать json'ы.

Ещё один способ можно применить при более-менее статичном наборе возможных параметров. Отдельным запросом получаете все возможные уникальные имена параметров в алфавитном порядке и в том же порядке джойните слева (left join) соответствующие значения. При агрегации вы просто собираете csv-строку с строковыми значениями параметров, а для тех параметров, которых нет, будет пустая строка или null.
Можно собирать не строку с разделителями, а массив строк, или json-список.

Вы смутили народ соей странной постановкой задачи.
В реальном мире смысл монеты ка краз в ее неуникальности и взаимной заменяемости с другими такими же. А у вас это не монеты, а, своего рода, токены. И если формулировать так, то станет гораздо понятнее.

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

Однако по постановке вопроса ясно, что вы хотите также понимать в какой-то момент сколько токенов у кажого пользователя. То есть существует какая-то функция нормирования, которая приводит токен к какой-то веичине объективно определяющей его ценность.
Тогда определить текущий баланс пользователя можно агрегацией - суммированием норм всех токенов, принадлежащих конкретному юзеру.

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

Эти три изменения должны быть в рамках атомарной транзакции. Если что-то пошло не так, то все три действия должны отмениться.

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

Да, возможны более сложные ситуации, когда вам нужно быстро получать не только баланс пользователя на текущий момент, но и баланс пользователя на любой конкретный момент времени в прошлом.
Очевидно, что вм для этого пришлось бы сделать снимок текущего состояния балансов пользователя, а потом пройтись в обратном порядке по всем его транзакциям в которых он был источником и приемником токенов и обратить все операции над копией его баланса.
Чтобы делать это быстро, то балансы пользователей на момент транзакции можно размещать в жарнале. Это избыточность, но она позволит мгновенно получать баланс любого польщователя на любой момент времени. Для этого нажно лишь найти саму старую транзакцию этого пользователя не позднее заданного времени и там будет нужное число. Этот поиск делается с логарифмической сложность.

Да как-как? как обычно
localtime >= open_time and localtime < close_time
UPD:
Не сразу понял в чем проблема.
Речь, похоже, о заведениях типа ночных клубов, которые работают, скажем, с 22:00 до 05:00 и нужно понять попадает ли какое-то время в этот интервал, если два времени оказались по разную сторону от полуночи.
Тут спасёт сложное условие:

SELECT *
FROM shop
WHERE
(open_time <= close_time) AND (localtime BETWEEN open_time AND close_time) OR
(open_time > close_time) AND NOT (localtime BETWEEN close_time AND open_time)

Это замечательно работает, если ваши магазины работают каждый день по одному графику, а если нет, то нужно строить расписание на неделю. Это доволно быстро работает, если хранить расписание в отдельной таблице в виде нтервалов работы в секундах от начала недели и ссылку (многие к одному) на учреждение.

UPD2: Перенесу, пожалуй, сюда и пример с недельным расписанием из своего комментария.

Интереснее когда график работы магазина разный в выходные и будни, причем, скажем, на выходных магазин открыт в полночь.
Ну, к примеру, пн-пт - 10:00-23:00 а сб-вс - 10:00-01:00.
Тут вообще интересно. Фактически магазин не работает в суботу с полуночи до часу ночи, но работает в понедельник с полуночи до часу ночи.
В таких случаях расписание лучше задавать набором интервалов в часах, минутах или, обычно, в секундах от полуночи понедельника.
В часах проще показывать на примере.
0-1, 10-23 - понедельник
34-47 - вторник
и т.д.
По-хорошему должен быть специальный бинарный тип данных, способный хранить такие интервалы эффективно и индексировать их.
Очевидно. что для выше изложенного графика таких интервалов надо около 7+2 - по одному основному на каждый день, час после полуночи понедельника, и час после полуночи воскресенья.
Итого 9 интервалов на магазин, если без перерывов. С обеденными перерывами будет 16 интервалов на магазин. В любом случае не критично. Просто нужно задавать реальное расписание магазина в формализованной форме (какой-то формулой) прямо в записи об этом магазине, а в таблицу с интервалами просто кэшировать развернутое расписание при апдейте формулы.
У нас точно также интервалами с кэшированием в отдельной таблице было устроено расписание ВУЗа и всё работало мгновенно.

Что-то у меня дежавю. Недавно вы с похожим вопросом сюда приходили.
Не задания ли это для какого-нибудь теста?
Да и вам намекали, что отвечать на такие вопросы удобнее, если вы не вот эту хрень рисуете в описании таблиц, а sql-дамп метаданных приводите. Там видно и ключи, и ссылки, и индексы. Да и выполнить такой SQL для эксперимента можно мгновенно. А вы игнорируете рекомендации.

Такого рода сортировки по сложным сложных джойнам и на довольно больших объёмах быстро работать не будут. Такие вещи решают денормализацией.
Можно сделать отдельную аггрегированную таблицу, которая будет 1к1 джойниться к вашей тблице продуктов и предоствлять уже посчитанные данные.

Такую таблицу считают первично один раз и на это не жалко 350с, а потом её можно поддерживать в акутальном состоянии триггерами или допилив бэкенд. Всё таки запись в аггрегируемые таблицы по времени не так критична обычно, как выборка этой статистики.

У вас максимальная модель выбирается среди всех продуктов: select max(model) from product
и это может оказаться не принтер. А потом вы ищете принтер с именно такой моделью. Видимо такого нет.

Ну так а в чем у вас проблема-то? Вы в принципе не знаете как запрос писать и это задание такое?
Если так, то данный ресурс не для этого.
Если у вас конкретный вопрос, то заайте его конкретно. Что именно у вас не получется?
Не ясно как сформулировать рамочные условия с интервалами, пересекающими конкретную дату?
Не понятно как сгруппировать интервалы по товарам?
Не знаете про coalesce?
Запутались с граничными точками интервалов?
В чем проблема?

Так себе идея динамически формировать таблицы, а потом схлопотать прилично геморроя, чтобы с этими таблицами бороться.
То что вам нужно написано вот здесь в документации.
Но что мешало разместить все данные в одной таблице, а то, что вы используете как добавку к имени ваших отдельных таблиц просто хранить в проиндексированном столбце?
Просто если вы не можете найти решение такого простого вопроса, есть вероятность, что вы ошиблись раньше, когда выбрали такое спорное архитектурное решение по динамическому созданию однотипных таблиц.

SELECT
  e.name, SUM(t.hours)
FROM 
  employees e
    JOIN time_reports t ON t.employee_id = e.id
GROUP BY e.id, e.name
ORDER BY 2 DESC
LIMIT 3

Вам нужно не группировку, а сортировку и оконную функцию.
Но вы же не удосужились написать о какой БД речь, как вам помогать?

На файрбёрде я уже не помню как такое делать. Тем более на современном. Давно не трогал.
Хранимку бы по-быстрому запилил и сделал в цикле по отсортированному селекту проверку на равенство ФИО с предыдущим. Если равно, то обнулял бы фио