Полная Версия: Флуд от темы про Query Builders
| Цитата (chee @ 6.01.2017 - 17:12) |
| мне лень искать |
чего ты искать собрался? Тут всего пару строк написать надо. Какой формат данных использовать, примеры инсерта/апдейта/селекта. Или ты никогда с датами не работал?
killer8080, мне лень искать сообще bestxp
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
| Цитата (chee @ 7.01.2017 - 13:12) |
| killer8080, мне лень искать сообще bestxp |
| Цитата (killer8080 @ 6.01.2017 - 17:01) |
| Покажи пример правильной работы со временем в MySQL? |
ладно не напрягайся, я понял что ты теоретик
| Цитата (killer8080 @ 8.01.2017 - 22:12) |
| ладно не напрягайся, я понял что ты теоретик |
конечно я не настолько прошарен в работе со временем в СУБД как ты, ведь я не использую её средства для работы с временем.
Перешел по ссылке, все равно не понял, что ты от меня хочешь с учетом его сообщения.
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
killer8080, теоретик без практики это гораздо лучше, чем практик без теории
_____________
Стимулятор ~yoomoney - 41001303250491
_____________
Стимулятор ~yoomoney - 41001303250491
| Цитата (chee @ 8.01.2017 - 22:41) |
| Перешел по ссылке, все равно не понял, что ты от меня хочешь с учетом его сообщения. |
там шла речь о пользе кверибилдера, его аргументом было - "легкость смены субд", одна из причин перехода - неумение работать с часовыми поясами в MySQL. Это был ответ на
| Цитата (chee @ 6.01.2017 - 16:53) |
| Цитата (killer8080 @ 6.01.2017 - 16:49) просто к делу нужно подходить с умом smile.gif зачем к этому подходить если можно не подходить? |
| Цитата (chee @ 8.01.2017 - 22:41) |
| конечно я не настолько прошарен в работе со временем в СУБД как ты, ведь я не использую её средства для работы с временем. |
не важно на какой стороне ты работаешь, важно как.
Ты сделал вброс, "в субд время надо хранить только в UTC". С этим никто не спорит, вопрос в каком формате? Если в DATETIME, то тут свои нюансы. Нужно постоянно помнить что на каждый чих в бд нужно всегда конвертировать все временные поля, опять же не все, а только те, которые являются абсолютными временными величинами, а не абстрактными. Т.е DATETIME почти всегда нужно, а DATE в принципе никогда (это же просто дата без времени
) и TIME чаще всего нет, если не привязано к дате. И об этом должен помнить не ты один, а все кто будет работать с твоей бд. Т.е должны быть внутренние соглашения внутри команды, как работать с датами в БД, и остается только надеяться чтоб никто не облажался. С TIMESTAMP нет этих проблем, достаточно один раз в коннекте засинхронизировать временные зоны и всё, твоё приложение на одной волне с субд. Если же ты начнёшь всё завязывать на приложение, тебе придётся городить огород с конвертацией ts туда обратно, и опять же возникает человеческий фактор, кто то забудет что нужно делать так INSERT ... (FROM_UNIXTIME(<?= time() ?>)), и сделает так INSERT .. ('<?= date('Y-m-d H:i:s') ?>') и запаришся потом искать где косяк. А все из-за того, что у кого то религиозная нетерпимость к работе с TZ в субд
| Цитата (Valick @ 8.01.2017 - 23:13) |
| killer8080, теоретик без практики это гораздо лучше, чем практик без теории |
теоретик без практики это чаще всего фантаст, сам не знающий о чём говорит
| Цитата (killer8080 @ 8.01.2017 - 23:18) |
| Нужно постоянно помнить что на каждый чих в бд нужно всегда конвертировать все временные поля |
да это так, и я не вижу в этом чего то страшного.
Я работаю с системой, которая так устроена. На одном из проектов мы импортируем по 100к записей из > 100мб xml файлов. И конвертация временных полей там далеко не самый ресурсоемкий процесс. Добавление и обновление записей у нас идет в основном через AR, она берет на себя все эти штуки с конвертацией.
| Цитата (killer8080 @ 8.01.2017 - 23:18) |
| INSERT ... (FROM_UNIXTIME(<?= time() ?>)), |
я не помню когда я последний раз вообще писал INSERT руками. Я даже не помню когда его кто-то из моей команды писал руками. AR такие банальные вещи делает сама. UPDATE вот делаем, там конвертировать приходится, но баги там не очень частые.
| Цитата (killer8080 @ 8.01.2017 - 23:18) |
| А все из-за того, что у кого то религиозная нетерпимость к работе с TZ в субд |
Можешь считать так.
_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
| Цитата (killer8080 @ 8.01.2017 - 19:18) |
| и опять же возникает человеческий фактор, кто то забудет что нужно делать так INSERT ... (FROM_UNIXTIME(<?= time() ?>)), и сделает так INSERT .. ('<?= date('Y-m-d H:i:s') ?>') и запаришся потом искать где косяк. А все из-за того, что у кого то религиозная нетерпимость к работе с TZ в субд |
Тут есть еще один нюансик. Гораздо более серьёзный, нежели смутная параноя chee от головняков в будущем, либо протекания (знаю, что перетекания) слоев 
, которые так не любит Santehnick.
Фишка в том, что если это атомарные запросы, и действо происходит на стыке дат, то можно облажаться даже с транзакцией. Причем хоть так, хоть эдак. Хоть средствами СУБД (причем пофиг какой), хоть таким спсобом INSERT ... (FROM_UNIXTIME(<?= time() ?>)).
Я обычно использую время приложения, но не текущее, а время запуска скрипта. Не знаю, как там в волшебной AR от chee делается, но я бы не полагался на это слепо.
, которые так не любит Santehnick.Фишка в том, что если это атомарные запросы, и действо происходит на стыке дат, то можно облажаться даже с транзакцией. Причем хоть так, хоть эдак. Хоть средствами СУБД (причем пофиг какой), хоть таким спсобом INSERT ... (FROM_UNIXTIME(<?= time() ?>)).
Я обычно использую время приложения, но не текущее, а время запуска скрипта. Не знаю, как там в волшебной AR от chee делается, но я бы не полагался на это слепо.
| Цитата (Valick @ 8.01.2017 - 19:13) |
| теоретик без практики это гораздо лучше, чем практик без теории |
| Цитата |
| В теории, теория и практика неразделимы. На практике это не так. © Yoggi Berra |
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (chee @ 8.01.2017 - 21:32) | ||
да это так, и я не вижу в этом чего то страшного. Я работаю с системой, которая так устроена. На одном из проектов мы импортируем по 100к записей из > 100мб xml файлов. И конвертация временных полей там далеко не самый ресурсоемкий процесс. Добавление и обновление записей у нас идет в основном через AR, она берет на себя все эти штуки с конвертацией. |
У тебя на AR конвертация средствами php, тут понятно что просто.
Но теперь остается главное - запросы к базе, где нужно конвертировать в sql. "Выбрать по субботам".
CONVERT_TZ() тут в общем случае не катит, т.к. он завязан на юникс отметке.
Надо значит самому TIMESTAMPADD или TIMESTAMPDIFF в зависимости плюс или минус от UTC. И хранить отметку в минутах.
Ладно если для текущего пользователя, тут с помощью queryBuilder можно это все обернуть(на пхп sql Expression сформировать), а есть же еще запросы где и по многим юзерам.
_____________
There never was a struggle in the soul of a good man that was not hard
| Цитата (Michael @ 9.01.2017 - 08:37) |
| а есть же еще запросы где и по многим юзерам |
даёшь каждому юзеру по запросу!!!
Michael, спасибо, постоянно забываю про этот аргумент, хотя собственно уже давно никому ничего не доказываю, поэтому как говориться аргументами не заморачиваюсь.
_____________
Стимулятор ~yoomoney - 41001303250491
Я ничего не доказывал, почитал обсуждение выше, и самому интересно стало как коллеги точно решают все проблемы хранения даты-времени в типе DATETIME под mysql. Вопрос чето не гуглится пока.
Или тут последует ссылка на ответ от bestxp что мол отказаться от мускуля?
Кстати хранить минуты, на которые корректировать под пользователя, понял что не прокатит, т.к. это не учитывает переход на летнее/зимнее время.
_____________
There never was a struggle in the soul of a good man that was not hard
Или тут последует ссылка на ответ от bestxp что мол отказаться от мускуля?
Кстати хранить минуты, на которые корректировать под пользователя, понял что не прокатит, т.к. это не учитывает переход на летнее/зимнее время.
_____________
There never was a struggle in the soul of a good man that was not hard
| Цитата (chee @ 8.01.2017 - 23:32) |
Цитата (killer8080 @ 8.01.2017 - 23:18) Нужно постоянно помнить что на каждый чих в бд нужно всегда конвертировать все временные поля да это так, и я не вижу в этом чего то страшного. |
необходимость постоянно что-то помнить, это держать мусор в голове :)
| Цитата (chee @ 8.01.2017 - 23:32) |
| Я работаю с системой, которая так устроена. На одном из проектов мы импортируем по 100к записей из > 100мб xml файлов. И конвертация временных полей там далеко не самый ресурсоемкий процесс. |
о ресурсоёмкости речи не было
| Цитата (chee @ 8.01.2017 - 23:32) |
| Добавление и обновление записей у нас идет в основном через AR, она берет на себя все эти штуки с конвертацией. |
то что прослойка делает конвертацию автоматом, только повышает человеческий фактор, бдительность притупляется.
| Цитата (chee @ 8.01.2017 - 23:32) |
| Цитата (killer8080 @ 8.01.2017 - 23:18) INSERT ... (FROM_UNIXTIME(<?= time() ?>)), я не помню когда я последний раз вообще писал INSERT руками. Я даже не помню когда его кто-то из моей команды писал руками. AR такие банальные вещи делает сама. |
да причём тут твоя AR? Это был пример взаимодействия между приложением и субд, какие бы ты прокладки там себе не подкладывал это не меняет суть дела. К тому же, а что AR за тебя решает стратегию хранения данных?
| Цитата (chee @ 8.01.2017 - 23:32) |
| UPDATE вот делаем, там конвертировать приходится, но баги там не очень частые. |
Во первых, какой смысл оставлять шанс им появится, если можно присечь человеческий фактор на корню
Во вторых, не выявленные баги не означают их отсуствия ;) просто видимо нет сложных выборок, завязанных на временные зоны, вот они и не проявляются :) .
| Цитата (twin @ 9.01.2017 - 06:28) |
| Тут есть еще один нюансик. Гораздо более серьёзный, нежели смутная параноя chee от головняков в будущем, либо протекания (знаю, что перетекания) слоев , которые так не любит Santehnick. Фишка в том, что если это атомарные запросы, и действо происходит на стыке дат, то можно облажаться даже с транзакцией. Причем хоть так, хоть эдак. Хоть средствами СУБД (причем пофиг какой), хоть таким спсобом INSERT ... (FROM_UNIXTIME(<?= time() ?>)). |
Это естественно, запросы разнесены во времени, если тебе нужно выполнить несколько вставок с одним и тем же временем, значит это уже работа с фиксированной отметкой времени, а не с текущей. Это специфика конкретной задачи, я бы не стал проецировать это как принцип работы с бд.
| Цитата (twin @ 9.01.2017 - 06:28) |
| Я обычно использую время приложения, но не текущее, а время запуска скрипта. Не знаю, как там в волшебной AR от chee делается, но я бы не полагался на это слепо. |
Опять же специфично для "приложения рожденного умирать", не всё в PHP сводится к обработке веб запросов, да и там это подход не всегда годится. Ещё есть долгоиграющие скрипты, например запущенные кроном ил демоны, там вообще нельзя использовать время запуска приложения как основу. В общем выбор решения определяется условиями поставленной задачи.
chee
ты вот говоришь, "никогда не используй TZ в субд" DATETIME UTC forever :)
А как ты будешь решать такую задачу:
Дамп
-- MySQL dump 10.13 Distrib 5.7.17, for Linux (i686)
--
-- Host: localhost Database: test
-- ------------------------------------------------------
-- Server version 5.7.17
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Dumping data for table `tz_test`
--
LOCK TABLES `tz_test` WRITE;
/*!40000 ALTER TABLE `tz_test` DISABLE KEYS */;
INSERT INTO `tz_test` VALUES (1,'2016-02-29 22:00:00','2016-02-29 22:00:00','Киев 2016-03-01 00:00:00'),(2,'2016-03-11 22:50:00','2016-03-11 22:50:00','Киев 2016-03-12 00:50:00'),(3,'2016-03-30 21:25:25','2016-03-30 21:25:25','Киев 2016-03-31 00:25:25');
/*!40000 ALTER TABLE `tz_test` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;Нужно выбрать все записи созданные в интервалах 00:00:00 - 00:59:59 за март 2016 по Киевскому времени. Вот решение с использованием TIMESTMP и time_zone
mysql> SET time_zone = 'Europe/Kiev';
Query OK, 0 rows affected (0,00 sec)
mysql> SELECT * FROM tz_test WHERE ts BETWEEN '2016-03-01 00:00:00' AND '2016-03-31 23:59:59' AND HOUR(ts) = 0;
+----+---------------------+---------------------+------------------------------+
| id | ts | dt | description |
+----+---------------------+---------------------+------------------------------+
| 1 | 2016-03-01 00:00:00 | 2016-02-29 22:00:00 | Киев 2016-03-01 00:00:00 |
| 2 | 2016-03-12 00:50:00 | 2016-03-11 22:50:00 | Киев 2016-03-12 00:50:00 |
| 3 | 2016-03-31 00:25:25 | 2016-03-30 21:25:25 | Киев 2016-03-31 00:25:25 |
+----+---------------------+---------------------+------------------------------+
3 rows in set (0,00 sec)
Как ты это будешь делать с DATETIME ?
Здесь расположена полная версия этой страницы.