Dotaz: Nelze změnit typ pole na not null - mysql

[Dalibor Smolík]

Zdravím, potřeboval bych u Debianu 10 opravit tabulku

MariaDB [prace]> alter table kontrakt modify cenaeurzaksk float not null;
ERROR 1265 (01000): Data truncated for column 'cenaeurzaksk' at row 1571
MariaDB [prace]>

V tomto sloupci měním pouze NULL za not null, nic víc.
v předchozí verzi mysql toto nebyl problém. Díky za tip ..

Odpovědi

[alkoholik]

Jsi si jisty, ze v tom sloupecku zadna NULL hodnota v tuhle chvili neni?

[Kit]

Proč vlastně musí být cena NOT NULL? Co tam dáš, když cenu nebudeš znát?

Evidentně se v tom sloupci nějaké NULL vyskytuje a proto databáze nedovolí změnu.

[Dalibor Smolík]

Pokud zadávám hodnoty ručně do databáze, změna proběhne. Ale přes PHP 7.3 změna nikoliv, pokud zadávám číslo. Změna se neprovede. V PHP 5.5 a minulé verze databáze vše fungovalo, jak má. Nevím přesně, kde se změnila pravidla.

[Kit]

S tím přece NULL/NOT NULL nemá nic společného.

Viděl bych to spíš na chybné používání db ovladače. Používáš MySQLi nebo PDO? Používáš prepared statements? Vkládáš tam čísla jako string nebo float?

[Dalibor Smolík]

Používám mysqli. Čísla tam vkládám jako string. Teď již u toho nejsem, trochu to prostuduji a pak dám vědět. Budu až v pondělí.

[Kit]

V tom případě může být problém desetinná čárka vs. desetinná tečka.

[Kit]

Ještě dodávám, že pro finanční hodnoty se nepoužívá typ float, ale decimal.

[Kit]

https://stackoverflow.com/questions/7828440/mysql-alter-table-modify-column-failing-at-rows-with-null-values

[Dalibor Smolík]

Ono to v podstatě funguje takto
alter ignore table kontrakt change column cena cena decimal(6,2) not null dafault 0;
ale v předchozí verzi nebylo potřeba takové změny provádět. Ale chovají se jinak i funkce php, takže se s tím trochu peru.

[Kit]

Zrovna u ceny bych NOT NULL nedával.

[j]

On se ale pocet (idealne taky null) tim nullem v cene dobre nasobi, vis? Jinak receno, cena urcite muze byt nulova nebo i zaporna, ale rozhodne ne null.

Pokracovani muze vypadat taky moc hezky, to kdyz mas trebas na fakture 30 polozek, a jedna z nich je null, tak se to uzasne scita. Tohle miva obzvlast vypeceny chovani (kazda databaze jinak) - klidne z toho vypadne "celkem 0" (nebo zase null). Jinak receno, zakaznik dostane zbozi, a system je spokojeny i bez placeni, protoze uhradit zbyva 0/null ...

A jasne, da se to osefovat, kdyz do kazdyho jednoho dotazu neustale ladujes neco na tema isnull(cena,0), coz ale neni reseni, protoze ty nevis, jestli ta cena vazne ma byt nulova. To uz je z pohledu systemu lepsi tam naladovat isnull(cena, 10000000000000), protoze to se aspon prevazne ten, co to ma zaplatiti, ozve. Nic to ale nemeni na veci, ze cena by nikdy null byt nemela, tak proc to nevynutit primo nastavenim pole.

[Peter Golis]

Pokiaľ je cena neznáma (teda NULL), tak by aplikácia nemala poskytnúť zakúpenie položky.

[j]

To je mozny, a osefujes to na jednom miste, jenze na ta data koukas jeste ze 30 jinych mist.

Neboj, na podobny vifikundace narazim da se rict denne. To se trebas takhle podivas po pole, a vidis 1,2,3,4, 6,12, 16, ... a reknes si jasne, je to cislo, takze napises ... where pole = 12, a za 1/2 roku (nebo taky za 10 let) ti zacne cosi kdesi hlasit nejaky hruzostrasny chyby ... protoze to pole je varchar(2), a nekdo vymyslel, ze tam nekde bude trebas A (ktery je tam klidne i tech 10 let), a tvoje uzasna databaze nezvladne implicitni konverzi (pricemz predchozi verze s tim problem nemela) => neumi z 12 udelat '12'.

Typicky se tohle projevuje pochopitelne po vsemoznych upgradech, specielne kdyz nejaka dobra duse mysli na hentu "bezpecnost".

Pripadne jeste krasnejsi je vzdycky deleni nulou ... Protoze ty sice mas x/y where y<>0, ale tvuj uzasnej databazovej endzajn to udela (logicky, jak jinak) opacne, nejdriv vsechno vydeli, a teprve pak filtruje. To si pak rikas, ze tu databazi nemoh navrhovat nikdo jinej nez zmrd s 10ti titulama. Vubec nejkrasnejsi je to pak v situaci, kdy ti tvoje vypecena databaze pokazdy pouzije jinej execution plan, takze se to deje jen nekdy a nekomu.

Pak samozrejme vymejslis zhuverilosti jako je select v selectu (pripadn selfjoin, nebo jeste hur, vsemozny temptable), abys to dokopal k cinnosti kterou chces ty.

[Dalibor Smolík]

No jo, pořád
Je mi to jasné. Databázi jsem v podstatě dával dohromady kolem roku 2001, od té doby jsem toho tam moc neměnil. Je mi jasné, že u cen (a i u jiných údajů, kde má být číslo) by NULL být nemělo, jde mi jen o to, abych to zpětně správně nastavil.
Pole pro ceny v té době bylo v různých měnách, vyplňovalo se jen podle skutečné měny (tenkrát byla i marka a šilink), zbytek zůstal bez údajů a teď to systém vyžaduje.

[Kit]

V tom případě bys tam neměl mít DEFAULT 0, ale nějakou hodně nesmyslnou hodnotu, která bude bít do očí. Jinak se ti bude stávat, že nějaké zboží budeš prodávat za nulovou cenu.

NULL se však chová o něco lépe, protože ti přímo signalizuje, že v tom poli je nesmysl a to při jakémkoli čtení či jiné manipulaci.

[Dalibor Smolík]

Tohle nehrozí, protože při fakturaci zadáváme cenu u každé položky zvlášť. Nemají totiž pevné ceny, které by byly zafixovány přímo v databázi u konkrétního výrobku a jen část výrobků se opakuje. Jde jen o měnu - Kč nebo EUR. A tam by mohlo dojít (dnes už jen teoreticky ) k uvedení NULL do jednoho ze sloupců.

[Michal]

To sis vycucal z prstu ne? Pri scitani hodnot z nichz jedna je null ti kazda databaze vrati null, coz je spravny vysledek. Pokud nejaka vrati neco jineho (jako 0 nebo nedej Boze soucet se zignorovanim te null polozky tedy jako kdyby null=0) ihned - nahlasit jako bug.

[kaaja]

Tak jsem udělal jednoduchý test na oracle a myslq a pokud dělám sum na sloupci, kde jsou null hodnoty, tak se chovají jako 0.

[j]

To skoro vypada soudruhu, ze si vzivote zadnou databazi nevidel, protoze tu meles uplne z cesty.

mssql:

select 1 + null ... null
select sum() ... 1

mysql dtto ... asi zazrak.

A to tomhle vis zjevne naprosty kulovy:

https://docs.microsoft.com/en-us/sql/t-sql/statements/set-ansi-nulls-transact-sql?view=sql-server-2017

Aneb jedna z moznosti, jak vyrazne zmenit prave chovani null.