|
|
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
для загрузки csv есть специальные инструменты, позволяющие напрямую загрузить в базу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2020, 11:51 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Zzz79 mayton Не знаю честно. У тебя есть в гитхабе макет этого? нет,это банк,у нас свой закрытый репозиторий Сделай в 5 строчек макет чтоб компилировался. Без ваших бизнесовых названий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2020, 12:06 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Когда твой скедюлер бин поднимается он должен что-то записать в логи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2020, 17:24 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Zzz79, так добавь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2020, 19:38 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Zzz79 а кто то во владике в это время тоже записал 11 и чтобы в базу тоже легло 11 а не 3) А когда кто-то во Владивостоке в 11:00 что-то внёс в базу, а в Москве кто-то в 10:00 как узнать кто из них был первый? А если вам просто цифры хранить, то используйте цифровое поле, а не TIME. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2020, 21:28 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Zzz79 Garrick пропущено... А когда кто-то во Владивостоке в 11:00 что-то внёс в базу, а в Москве кто-то в 10:00 как узнать кто из них был первый? А если вам просто цифры хранить, то используйте цифровое поле, а не TIME. вообще нам не нужно знать кто был первым) нужно в печатках потом правильно отображать время я столкнулся с тем что мы в вводим 11 +3 в джесон - в базу пишет 8 на печатке выходит естественно 8 рукалицо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2020, 22:01 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Zzz79 mayton,да это понятно) я хочу разобраться в причние пс.майтон скажи у нас база постгрес - мы пишем даты согласно тайм зоне в бд они пишутся по гринвичу тоесть я сижу в мск ввел 11 в базе 8 мне интересно есть ли способ чтобы все записи писались как положено чтобы их не надо было конвертировать тоесть я сижу в мск записал в мск 11 и в базу тоже легло 11 а не 8 и потом чтобы можно было это 11 достать а не 8) а кто то во владике в это время тоже записал 11 и чтобы в базу тоже легло 11 а не 3) 1) Надо смотреть какой тип данных времени у вас в таблице. https://www.postgresql.org/docs/12/datatype-datetime.html 2) Надо смотреть как приложение настраивает свою локаль (язык страна часовой пояс) Для java это тоже касается. И какой тип данных JDBC вы выбрали чтобы представлять дату. Разумеется приложение должно фиксировать дату с учотом поясов чтобы правильно сделать comparison. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.04.2020, 22:43 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Zzz79, Детский вопрос. В аппСервер с клиента приходит 2013-02-25 18:25:10 +03 Хочешь обрезай, хочешь не обрезай. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2020, 07:36 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Zzz79 mayton Разумеется приложение должно фиксировать дату с учотом поясов чтобы правильно сделать comparison. зачем? Эта дата используется лишь для распечатки документов на кредит) типо дата подписи или что то в этом роде) тоесть если клиент запросил кредит во владике -зачем мне в базу писать гринвич+ зона =чтобы потом обратно все жто дело преобразовывать,вместо того,чтобы записать время фактическое? Не совсем правильный вопрос зачем. Вопрос как правильно. Если твоя задача работает в системе без учота часовых поясов - то ты выбираешь ТИПЫ данных для БД и JDBC которые не хранят часовой пояс. Если твоя задача работает в нескольких часовых поясах и для нее важно ФИКСИРОВАТЬ время события (чтобы в будущем принимать решения о причинно-следственной связи между событиями) то надо соотв. брать SQL/JDBC типы с зоной. Зональны типы можно конвертить и форматировать красиво чтоб публиковать +1,+2,+3 e.t.c. Есть еще третий (гибридный вариант). Твоя систма фиксирует время зонированное но в базе или в системе время сводится к времени UTC. Так мы делаем. С UTC проще делать арифметику т.к. это просто целое число. Правда мы теряем сведения о зоне. Но нам пофиг. Если время например паблишится по Нью-Йорку всегда независимо от того из какой зоны пришло событие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2020, 11:13 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Zzz79 и вот я хочу чтобы другой сервис ,который например находится во владике при распечатке документов выводил время обращение клиента 11.40 Я не могу рассказать это тебе оперируя гуманитарным текстом. Очевидно что надо что-то во что-то конвертить. Я уже жду исходников и DDL таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2020, 11:21 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Zzz79, Это спринг на тебя так влияет? Или облака?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2020, 11:36 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Zzz79мы должны убрать тайм зону из базыбазу держи в одной нулевой зоне, на клиенте конвертируй ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2020, 12:13 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Zzz79 Alex_Ustinov пропущено... базу держи в одной нулевой зоне, на клиенте конвертируй да у нас так и реализовано-я просто не пойму зачем туда сюда конвертировать дату эту? ведь потребителю важно локальное время подписанта - поэтому получается я сначала дату кладу с тайм зоной потом обратно эту дату переконвертирую Что важно потребителю - это business requirements ТВОЕГО приложения. И мы их не знаем ясен пень. В некоторых системах трекается два времени. Время фиксации события в системе. И время юридическое. Например договор был составлен вчерашним числом но заведен в систему сегодня. Две даты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2020, 12:50 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Я могу ответить на вопрос - "как сделать чтобы". Но я не отвечу тебе на вопрос "почему". Это - к твоим архитекторам и бизнесам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2020, 13:10 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Zzz79 Эта дата используется лишь для распечатки документов на кредит) типо дата подписи или что то в этом роде) О! Это вообще тема. Задачка для первого класса: Условие: Клиент 10-го числа в 7 утра во Владивостоке подписал кредитный договор. В Москве в это время ещё 9-е число. В конце месяца по кредиту начисляются проценты и, как правило, это делается в центральном офисе в Москве. Вопрос: За какое количество дней будут начислены проценты? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2020, 13:11 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Я-же говорю. Comparison двух дат. Или вот еще вариант - календарная арифметика интервалов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2020, 13:13 |
|
||
|
MySQL очень медленный
|
|||
|---|---|---|---|
|
#18+
Zzz79то есть ты пришел во владике взял кредит- поставил подпись в 11 00 ,значит это время должно вылезти и в мск при распечатке доков поэтому я не пойму сакрального смысла конвертить 11 .00 сначала в 3.00 ,а заем обратно)ничего непонятно... но вроде все об одном. В доке должно стоять 11:00 (GMT+10) г.Владивосток (т.е. в базе будет 01-00). А то он прилетит в МСК и возьмет еще один кредит в 9-00 по МСК, ведь в МСК еще не будет 11-00..)) Так работают все сайты..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2020, 17:48 |
|
||
|
|
start [/forum/topic.php?fid=59&msg=39946684&tid=2120836]: |
0ms |
get settings: |
9ms |
get forum list: |
6ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
90ms |
get topic data: |
3ms |
get forum data: |
1ms |
get page messages: |
315ms |
get tp. blocked users: |
0ms |
| others: | 8ms |
| total: | 434ms |
| 0 / 0 |
