set bla = null 

create table blabla (
 bla int not null
);

insert into blabla values (1);

update blabla set bla = null;

PostgreSQL: 

"ERROR: null value in column "bla" violates not-null constraint
SQL state: 23502"

MS SQL Server: 

"Cannot insert the value NULL into column 'bla', table 'testpad.dbo.blabla'; column does not allow nulls. UPDATE fails."

MySQL: Na? Na? NA? 

"1 rows affected, 0 rows found."

(Aki ezt előnynek meri felhozni, azon rituális áldozást fogok bemutatni Manyeyeballs Úrhoz és agyon csapom a MySQL kinyomtatott forráskódjával. Teljesen jól illik ez a hulladék a PHP elbaszott type jugglingjéhez.)

( Snitt v | 2012. 06. 25., h – 11:11 )

na nemazé, hogy védjem, de:

mysql> create table blabla (
-> bla int not null
-> );
Query OK, 0 rows affected (0.09 sec)

mysql>
mysql> insert into blabla values (1);
Query OK, 1 row affected (0.09 sec)

mysql>
mysql> update blabla set bla = null;
Query OK, 1 row affected, 1 warning (0.10 sec)
Rows matched: 1 Changed: 1 Warnings: 1

mysql> show warnings;
+---------+------+-----------------------------+
| Level | Code | Message |
+---------+------+-----------------------------+
| Warning | 1048 | Column 'bla' cannot be null |
+---------+------+-----------------------------+
1 row in set (0.00 sec)

mysql> select * from blabla;
+-----+
| bla |
+-----+
| 0 |
+-----+
1 row in set (0.00 sec)

mysql Ver 14.14 Distrib 5.5.24, for Linux (i686) using readline 5.1

( Gyuszk v | 2012. 06. 25., h – 12:49 )

Azért a postgresql sem tökéletes, mi a db-szintű enumokkal szívtunk, az lett a vége hogy kivágtuk és a check constraint lett belőle (textual típus). Csak egy apró hint: 9.1 előtt 6 lépésből áll egy létező enumhoz opció hozzáadása, amennyiben egy egy oszlop már használja típusnak (ismétlendő 3 lépés minden tovbábbi oszlopnál), 9.1 -ben már van add option szerűség, de tranzakcióban nem használható, eldobni viszont lehet! (érted: egy opció hozzáadás kevésbé erős művelet mint az enum eldobása, mégis csak az utóbbit engedélyezik tranzakcióban).
A DB migrációs eszközök, mint a liquibase persze tranzakcióban futnak (és egyébként is, ne hakkoljunk).
Mindegy, ne DB-flameljünk :)

--
http://neurogadget.com/

Ismerem a szívásokat a pg+enummal.

Ami nekem viszont helyből fura, hogy miért engedi eldobni, főleg tranzakción belül. Az ALTER az DDL és tudtommal a PostgreSQL nem enged semmilyen DDL utasítást tranzakción belül csak DML-t.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( hrgy84 | 2012. 06. 25., h – 17:04 )

Asszem ha van defaultja a columnnak, akkor az lesz berakva a 0/null helyett. Mondjuk ezzel egyutt gyasz.

Update: hmm... vagy ez csak az inzertre vonatkozik?
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( zmb | 2012. 06. 25., h – 17:40 )


mysql> create table blabla (
-> bla int not null
-> );
Query OK, 0 rows affected (0.17 sec)

mysql> insert into blabla values (1);
Query OK, 1 row affected (0.12 sec)

mysql> update blabla set bla = null;
ERROR 1048 (23000): Column 'bla' cannot be null

A trukk:

mysql> SET sql_mode = 'TRADITIONAL';
Query OK, 0 rows affected (0.00 sec)

Mielott nagy mellennyel kijelentunk ilyeneket, erdemes azert vegig gondolni. Tegyuk fel, hogy tenyleg valamikor a mysql igy kezelte a null-os oszlopokat. A mysqlt hasznalo fejlesztok erre a viselkedesre szamitottak, amikor programokat irtak. Jottek az ujabb verziok, a visszafele kompatibilitast meg kellett orizni, elvegre nagy blama lett volna, ha hirtelen sok-sok program nem mukodott volna, mert megvaltozott a mysql viselkedese. Raadasul nekem az a gyanum, hogy a mai napig keszulnek olyan kodok, amik ezt a viselkedest feltetelezik. Az, hogy a mysql ezt a viselkedest allithatova tette, egy nagyon jo megoldas, mert igy a regi programok tudnak mukodni, de aki mar az ertelmesebb, szigorubb viselkedest akarja, az konnyeden at tudja allitani.

Hasonlo jelenseg mashol is fellelheto. Pl. javaban van 1-2 deprecated osztaly es fuggveny, de a mai napig nem irtottak ki (es talan sohase fogjak). Masik kivalo pelda az x86 architektura. A mai napig valos modban indul el (mintha csak egy XT lenne).

Ember! A NULL nem azonos a 0-val, márpedig itt NULL -> 0 konverzió történik ami sehol, soha nem védhető. Ha valaki nem tanulta meg, hogy a 0, mint szám, a nulla hosszúságú string és a NULL érték az HÁROM, különböző, nem keverhető dolog az SQL-ben, az fogjon egy kapát, és menjen kapálni.
Egyébként meg ha egy constraint-et megsért egy művelet, az mi a lópikuláért van hatással az érintett adatra?! Ilyen alapon egy uniq esetében is mondhatná, hogy warning, már van ilyen, és bebacarinthatna egy nullát (akár sokadikként is) a táblába, aztán az ember néz ki a fejéből, hogy mi van.

Félreérted, nem az a probléma, hogy megőrizték a visszafelé kompatibilitást (egyébként ez dícsérendő). A probléma azzal van, hogy ezt valaha így implementálták. Értem én, hogy a MySQL-nél sok mindenben tettek a szabványra nagy ívben és úgy vagy azt implementálták, ami gyors/gyors tud lenni, csak ugye most látjuk az eredményét. Különféle módok, figyeljen még erre is az ember stb. stb. stb.

Arról nem is beszélve, hogy amit csinál, SQL szabványt tekintve legalább annyira hülyeség, mint PHP-ben a 0 == "" (true), 0 == null (true), "" == null (false).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Szerintem te nagyon rosszul értelmezed az adatbázis kezelők [és a különféle constraintek] kapcsolatát: az adatbázis-kezelő dolga, hogy fenntartsa az adatbázis konzisztenciáját, nem az enyém, hogy fejben tartsam egy random elém kerülő DB struktúráját.

Nem csak alkalmazásból lehet SQL utasítást kiadni, hanem kézzel is. Az input jelen esetben a mysql konzolon jött létre.

Szerk: Na jó, nagyon kajakóma van (még mindig) és úgy is rég volt hup certificated autós hasonlat:

Hh kiszedhetetlen iBenzinTankPro van a kocsiban es te arra utasitod a szerelot, hogy szedje ki, akkor ne ures tankot rakjon mar bele. ( :) )

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nincs mit elosztani, itt a mysql a hülye. Normális RDBMS-ben a NULL a 0 és a "" teljesen mást jelent. Ha NULL-t akarok beszúrni valahova, ahova explicite TILOS, akkor ne konvertálja már át önhatalmúlag, ugyanis így nem az kerül a DB-be, ami elindult befelé, hanem valami egészen más; a constraint tegye a dolgát, és akadályozza meg a hibás adatnak a db-be kerülését, és hasaljon el rajta az insert/update.

Azert kulonbseg van a Java-beli osztalyok, es egy definialhatoan HIBAS mukodes kozott. Ez egy BUG, akarki akarmit is mondjon, az SQL szabvanyok eleg durva megsertese. Jo, igen, valaki regen igy implementalta. Bar mar ez is hulyeseg volt, a multon nem lehet valtoztatni. De konyorgom, jo eselye van annak, hogy ez egy MySQL 3-as kod, azota volt 2 fo- es kurvasok alverziovaltas (de meg ha MySQL 5-os kod is, akkor is minimum 60 alverziovaltason vagyunk tul). Nem tudom elkepzelni, hogy ma, az internet koraban, ahol egy fejleszto nem tud ket sort irni neked a google es ugy egyebkent az internet hasznalata nelkul - szoval az internet koraban ne lehetne ot alverzion belul kiszedni az ilyen oruleteket. Nem olyan nehez am, csak kommunikalni kellene.

Ha valaki egy bugra epitette a programjat, az kerlekszepen szopjon. Semmilyen szabvany szerint nem ertelmezheto mukodes az, amit a MySQL csinal.

Azt mar csak halkan teszem hozza, hogy ha meg akartak orizni a kompatibilitast, am tegyek. De ezt a hibas mukodest, mint default mukodest hozni... Mert ha valami konfig opcio/extra SET utasitas moge van rakva, a kutyat nem erdekli.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Tök mindegy, el van ...va, mert a constraint nem arról szól, hogy konvertáljon valamit valami mássá, hanem arról, hogy adott érték NEM kerülhet be a táblába. Mit szólnál hozzá, ha egy int mezőbe beszúrni kívánt 'A' esetén egy warning után beírná a mezőbe, hogy 65? Vagy nem is 65, hanem 1, mert az ABC első betűje? Vagy 42, mert csak?! Most a NULL esetén ilyet csinál, tetézve azzal, hogy a NULL a 0 és az '' értékek nem azonosak, tehát a konverzió logikailag HIBÁS. A NULL ugyanis azt jelenti, hogy nincs értéke az adott mezőnek, a 0 meg azt, hogy az értéke nulla.
Aki ezt a különbséget nem képes felfogni, az DB-hákolás helyett kapáljon inkább.

Igen, azert, mert nehany balfasz nem tud normalisan kodolni. A magic_quotes is epp amiatt volt, hogy rohadnanak meg mind. (mondjuk van ra include-olhato scriptem, ami kikapcsolja, visszacsinalja, hogy utana normalisan lehessen kezelni)

--
a publikus az egy JOGI fogalom abban az értelmezésben ahogy mi használtuk! nem műszaki. - RockWood1911

( dpalffy | 2012. 06. 26., k – 14:10 )

Én úgy döntöttem, hogy nem akarok többé MySQL-t látni, amikor egy minor verzióban egy ilyen változtatás miatt sikerült jópár korrupt táblát gyártanunk:

D.1.97. Changes in MySQL 5.0.2 (01 December 2004)
Incompatible Change: The precedence of NOT operator has changed so that expressions such as NOT a BETWEEN b AND c are parsed correctly as NOT (a BETWEEN b AND c) rather than as (NOT a) BETWEEN b AND c. The pre-5.0 higher-precedence behavior can be obtained by enabling the new HIGH_NOT_PRECEDENCE SQL mode.