SUM столбца чисел с запятой?

Question

[Константин KOltin]

В итоге вычисляется только целые, десятки и сотни не учитывает.
48,22
48,18
65
30,16
50
35,17
28,41
150
27,04
141
33,56
30,20
30,12
45,21
90
100
115
180
10,04
15,05
4,02

CREATE TABLE excel (
    Start varchar(255),
    Duration varchar(255),
    Position varchar(255),
    Volume varchar(255),
    Sensor_name varchar(255),
Geofences_Objects varchar(255),
    Fueled varchar(255),
    Deviation varchar(255)
);

Comments

[FanatPHP]

Может быть, не писать в БД кривые данные "с запятой"?

[Константин KOltin]

FanatPHP, все возможно, направьте меня на правильный путь.

[Slava Rozhnev]

Пожалуйста, покажите структуру таблицы

[Константин KOltin]

Slava Rozhnev,

CREATE TABLE excel (
    Start varchar(255),
    Duration varchar(255),
    Position varchar(255),
    Volume varchar(255),
    Sensor_name varchar(255),
	Geofences_Objects varchar(255),
    Fueled varchar(255),
    Deviation varchar(255)
);

[FanatPHP]

правильный путь - писать в правильном формате, с ТОЧКОЙ
в поле правильного формата, DECIMAL

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

[FanatPHP]

Slava Rozhnev, послушай, что тут про структуру таблицы неясно-то?

[Константин KOltin]

FanatPHP, спасибо.

[FanatPHP]

Дмитрий Гординский вот чего ты опять выводишь всякий мусор в топ?

[Slava Rozhnev]

Пожалуйста, посмотрите, как преобразовать вашу таблицу в правильный тип
https://sqlize.online/sql/mysql57/087b4a96b9833f28...

[Константин KOltin]

Slava Rozhnev, спасибо

[Дмитрий Гординский]

FanatPHP, лол, я тот тут при чем?)

[FanatPHP]

Дмитрий Гординский, а если подумать?

[Дмитрий Гординский]

FanatPHP, ты меня тэгал - ты и рассказывай)

[FanatPHP]

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

Answer 1

[FanatPHP]

Если данные должны суммироваться, то никакой запятой в них быть не должно. Десятичный разделитель для данных в mysql - ТОЧКА.
И числовые данные надо хранить в предназначенных для этого типах полей.
Со списком можно ознакомиться в документации: https://dev.mysql.com/doc/refman/8.0/en/numeric-ty... и выбрать наиболее подходящий. Это может быть либо тип с фиксированной точкой (DECIMAL), либо с плавающей (FLOAT).

Comments

[Владимир Коротенко]

Если данные должны суммироваться, то никакой запятой в них быть не должно. Десятичный разделитель для данных в mysql - ТОЧКА.

Умник а что если эти данные приходят извне и разделитель у них запятая, и менять локаль запрещено.

[Vitsliputsli]

Владимир Коротенко,

Умник а что если эти данные приходят извне и разделитель у них запятая, и менять локаль запрещено.

во вне они могут хранится как угодно, в реляционной базе данных, так чтобы было удобно с данными работать, и удобно должно быть в первую очередь СУБД. Если мы, конечно, ожидаем от нее какой-то производительности. Если нет, то можно хранить хоть в json, хоть в файлике.

[Владимир Коротенко]

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

из последнего похожего. трекер отправляет широту и долготу в зависимости от локали, то есть пресловутые точки и запятые, фирменная тулза пишет это все как строки. Судя по коду они тренировались на sqlite, потом добавили нормальные бд

[FanatPHP]

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

[Vitsliputsli]

Владимир Коротенко, да, бывает сложнее, но здесь то, все просто. Во вне может хранится как угодно, хоть латинскими цифрами, но, убить производительность запросов, просто потому, что было лень подготовить данные - это странно.
Вот спросит вас джун на кодревью: "сеньер-тимлид-архитектор почему здесь число хранится как строка, тем более что уже есть запрос на подсчёт суммы?". Что вы ему ответите? Не было времени. Но он же ответит, что это 1 строчка и будет прав.
В реальности далеко не всегда делаешь по учебнику, но в любом случае всегда должно быть обоснование почему. Можем сделать проще и быстрее - отлично, но должны быть уверены, что сможем дальше масштабироваться и это не нанесет вреда в будущем. Подход “здесь и сейчас" как правило провален, т.к. съэкономленные 6 часов, в будущем превратятся в 6 недель, а то и месяцев разгребания последствий ошибки в архитектуре.
И это не дело рефакторинга, это просто ошибка, т.к. изначально видим, что решение приводит к деградации производительности и не имеет никаких плюсов.

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

[Владимир Коротенко]

Vitsliputsli, один из примеров я привел. Коробочное решение которое нет возможности изменить. Второе легаси. Третье данные льются в тупую бд которая не понимает ничего кроме строк.

Это опять же сугубо из опыта.

[Vitsliputsli]

Владимир Коротенко, здесь СУБД MySQL, если мигрируем, то нужно мигрировать. Легаси - это легаси, а ошибка хоть в старом коде, хоть в новом остается ошибкой и ее нужно править. Коробочное решение имеет свою БД, лазить в чужую БД это очень плохое решение.
Как бы исторически не сложилось, какой бы код не попал в поддержку, чем раньше ошибка будет исправлена, тем меньше последствий, тем меньше работы в будущем, т.к. оттягвание решения лишь усугубляет. Это тоже из опыта.
Не пытаюсь убеждать, что только так, но автор вопроса должен понимать, что за сиюминутные костыли может быть потом очень больно.

[Владимир Коротенко]

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

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

Далее насчет коробочных решений и их баз. Многие просто не предоставляют api или же он настолько ущербен что лучше уж самим.

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

[Vitsliputsli]

Владимир Коротенко, нет никакого совершенного кода, в принципе. Есть компромиссы, есть специализированные решения, а есть просто ошибки.
Бизнес не пишет код за программиста, бизнес не заставляет писать с ошибками, бизнес не придет и не скажет, у вас тут нет такой ошибки в коде, нужно ее срочно сделать. Да, бизнес хочет быстрее и дешевле, но код он не пишет. Ну нельзя постоянно во всем винить бизнес.
Но, такое возможно тогда, когда тимлид не умеет взвешивать риски и требует делать "тяп-ляп". Стоит ли говорить, что из таких контор нужно бежать как можно быстрее.
Безусловно есть решения, где нет api, в этом случае необходимо его сделать, либо иную прослойку. Да, можно забить, по принципу "и так сойдет", свалив все на бизнес. И через год или 2, идти к бизнесу объяснять, что нам нужно где-то полгода, чтобы переделать весь наш код, ведь в коробочном решении изменилась версия и нужно все переделывать, т.к. написано дохрена и больше запросов лазающих напрямую в базу. Думаю, бизнес сделает выводы о компетенции специалиста, и будет прав, а крики "меня заставили" пропустит мимо ушей.
В общем, можно и так, но я бы не стал.

Answer 2

[Владимир Коротенко]

Где то так, но лучше измените типы в бд

SELECT SUM(duration) as dumb,
SUM(CAST(REPLACE(duration,',','.') AS DECIMAL(30,2))) as casted 
FROM test.testtable;

Comments

[FanatPHP]

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

[Владимир Коротенко]

FanatPHP, ваше мнение очень важно для нас