у самого таймстампа может быть только UTC; думаю, с этим согласны все, поэтому непосредственно хранить таймзону таймстампа - это бессмысленно

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

а календарь как же? а примеры из статьи?

у самого таймстампа может быть только UTC; думаю, с этим согласны все, поэтому непосредственно хранить таймзону таймстампа - это бессмысленно

я думал у таймстампа может быть любое время...

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

в том числе, я не знаю точно, как это реализовано внутри постгре, но, насколько понимаю, DATETIME WITH TZ там сохраняет таймзону согласно описанному выше принципу - и да, это хорошо

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

Но так постгре не работает же, тут они с mysql на равных

кто придумал TIMESTAMP WITH TZ - я не знаю, это противоречит здравому смыслу

ох

царёвщина, как она есть

А, ты именно про datetime with tz? Интересно

я думал у таймстампа может быть любое время...

таймстамп - это количество секунд с начала unix epoch. де-факто у него вообще нет таймзоны, просто это количество можно приплюсовать к 1970 и получить соответствующее время в UTC

мне кажется, это ты завёлся

таймстамп - это количество секунд с начала unix epoch. де-факто у него вообще нет таймзоны, просто это количество можно приплюсовать к 1970 и получить соответствующее время в UTC

ну так в случае бд это не так

* не совсем так

ну так в случае бд это не так

почему? потому что стандарт позволяет задавать его в виде строки с датой, которая конвертируется внутри движка в таймстамп?

да именно

это называется UNIX timestamp. А timestamp — это просто слово в английском языке. отметка во времени, без привязки к unix, epoch, 1970 и прочему

да именно

но это просто синтаксический сахар

То есть внешне он ведет себя не как количество секунд с времени а как обычная дата с таймзоной. Ну сахар, но тем не менее.

ну, здесь уже у кого какой вкус

Вдруг кто тут не чувствует этот момент ;)

Просто из-за таких разнотолкований и возникает недопонимание. Один напишет как удобно в постгре сохранять таймстамп с таймзоной, а другой потом ходит и всем рассказывает какие идиоты в постгре сделали поддержку таймзон у таймстампа :) Хотя в общем то первый прав.

а третий идиот расскажет, как разрабы в mysql ничего не понимают в таймзонах

мне кажется, это ты завёлся

я так и буду продолжать это форвардить, хорошо?

Ну это неконструктивное и слишком жесткое заявление. Но вот то что в нем не реализовано такое поведения с явными таймзонами это конечно недостаток.

хорошо

ну вот и славно

Ну это неконструктивное и слишком жесткое заявление. Но вот то что в нем не реализовано такое поведения с явными таймзонами это конечно недостаток.

здесь вообще никаких возражений. более того, есть баг репорт про это, сейчас найду

вот https://bugs.mysql.com/bug.php?id=6742

но что интересно, багрепортер был в тех же самых заблуждениях, что и @etkee

был ещё worklog про это, если память не изменяет

да, вот он: https://dev.mysql.com/worklog/task/?id=3744

у меня сейчас нету потсгри под рукой, но мне удивительно что datetimetz хранит таймзону, если это действительно так то будет совсем другой разговор ;)

нет, не хранит

Вам не кажется что работать с json в БД это адовое говно? :D

Вам не кажется что работать с json в БД это адовое говно? :D

это только кажется

а потом обмажешься

Вам не кажется что работать с json в БД это адовое говно? :D

coub в постгре хранят json, например

Каждый раз в проекте вопреки моим возражениям суют данные в json, и проходят все стадии: 1) Ой как круто, не надо больше создавать этих таблиц со схемами и типизацией и тормозами, все работает в одном месте. 2) Давайте понапишем 100500 классов для парсинга всего этого добра. 3) Ой а чего это тут вместо числа 0 записывается пустой массив [] ? Ну ладно напишем скрипт фиксящий. 4) Ой, эти пустые массивы продолжают прибывать! Данные побиты, клиенты в ярости! Что же делать, прогромиировние это так трудно! 5) Нам нужна типизация данных! Давайте вкорячим json validation schema! 6) Вкорячили, теперь все тормозит :( 7) See point [1)] Wait, oh, shit, ...

Вам не кажется что работать с json в БД это адовое говно? :D

при каком-нибудь event sourcing выбора особого нет, разве что на другой формат сменить

ну и как костыль для хранения небольшого массива атрибутов, чтобы избегать джойнов

ну и как костыль для хранения небольшого массива атрибутов, чтобы избегать джойнов

особенно когда в mysql вообще нет такого объекта как массив

Задайте этот вопрос Бартунову. Очень много красивых слов услышите о том, что json в постгресе - это наше всё

Задайте этот вопрос Зайцеву, он ответит, что все как обычно зависит от многих условий

Задайте этот вопрос Миловидову. Он вам ответит, что JSON - это вообще не данные, а мусор

Дальше выбирайте, какая точка зрения ближе идеологически :) потому что все правы

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

Сложно сказать, кто там чего думает. Индустрия в среднем по больнице стремительно тупеет, я не всегда успеваю следить

Но у json в рсубд есть свои применения. Мне кажется, их не так уж мало

Вот по моему наблюдению - проблемы json сильно перевешивают преимущества уже как минимум в двух случаях: 1) Когда в структуре json есть айдишники других колонок других таблиц, то есть потенциальный foreignKey 2) Когда в структуре json прослеживается более-менее постоянная схема, но этот факт не учитывают.

Да, он для других случаев

а ещё не всегда всё под капотом хорошо

ну и как костыль для хранения небольшого массива атрибутов, чтобы избегать джойнов

Для массива атрибутов согласен, почти идеальный вариант :)

Для массива атрибутов согласен, почти идеальный вариант :)

для тех кто часто сталкивался с хранимками которая в цикле идет по строковому массиву и что-то делает - это просто 10 оргазмов и прыжок с парашютом одновременно

Оракл показывал презентацию всех бонусов mysql 8 на примере конкретного приложения (продажа билетов). Json там тоже упоминается именно в этом контексте: массив атрибутов

Оракл показывал презентацию всех бонусов mysql 8 на примере конкретного приложения (продажа билетов). Json там тоже упоминается именно в этом контексте: массив атрибутов

а это было до того, как в 8 версии они собрались переделывать json под стандарт ISO?

или после

Это было позавчера

им бы ещё в сторадже всяких фишечек наделать, и может быть уже жизнеспособно будет

У них в сторадже уже столько фишечек, что остальные будут ещё много лет догонять. Включая большой оракл :)

ммм, например? или есть где посмотреть/почитать?

Надо смотреть, выложили они презентацию или нет. Я с телефона, посмотрю позже

есть ли смысл разделять таблицы user когда много полей? на user_settings , user_profile

Если у тебя частая работа с легковесной таблицей user_profile и тяжелой user_settings, то да, имеет смысл. И сделать между ними отношение one-to-one

Я так делал, одна таблица users с 3-4 базовыми полями, которая все время дергается, и вторая таблица users_profile с кучей доп. полей, которые читаются только изредка.

есть ли смысл разделять таблицы user когда много полей? на user_settings , user_profile

Смотря какую конкретную проблему решаем. А если нет проблемы, то не надо

им бы ещё в сторадже всяких фишечек наделать, и может быть уже жизнеспособно будет

А расскажи какие фишечки в сторадже тебе нужны?

индексацию json полноценную, без всяких generated columns , функциональные индексы, например

Ну во-первых это не сторадж в моём понимании. А во-вторых, generated columns в качестве функциональных индексов может выглядят не так красиво синтаксически, но в остальном, какие с этим проблемы?

Место лишнее занимают, как это что)

Плюс это не полноценная замена

Функции только детерменированные

Свои использовать нельзя

индексацию json полноценную, без всяких generated columns , функциональные индексы, например

Если это там выше объявлялось как фишечки которые другим догонять то ой ой :(

Привет

Ваш гуи

Немного не гуит

(

Баг phpMyAdmin?

Или я не правильно все таки запрос сделал?

Если бы ты сделал запрос неверно ты бы не получил 10 записей

лучше проверить из консоли

Так из консоли все норм

Даже пруфы есть

В консоли в запросе нет ORDER BY time

В консоли в запросе нет ORDER BY time

да там нет разницы

только порядок меняется

кстати в консоли тоже с ордер работает

Действительно странно

хай

можно задать вопрос?