Forum » Programiranje » Ničle v SQl tabeli
Ničle v SQl tabeli
kuall ::
Ta forum je samo tekmovanje, kdo bo znal bolje užalit. Beda. Prav, pa ne bom več pisal. Meni tekmovanje v tem, kako en druzga bolj užalit ni glih užitek.
Moderatorji: izgubili ste še enega člana, ker niste brisali žaljivih postov.
Moderatorji: izgubili ste še enega člana, ker niste brisali žaljivih postov.
Zgodovina sprememb…
- spremenilo: kuall ()
Akira_ ::
Ti si začel.
Sedaj ti pa ni všeč: the taste of your own medicine...
P.S. Upam da si se vsaj kaj naučil od pametnejših in izkušenejših od sebe.
P.P.S. Povej kje delaš, da vemo katerega podjetja se izogibat.
Sedaj ti pa ni všeč: the taste of your own medicine...
P.S. Upam da si se vsaj kaj naučil od pametnejših in izkušenejših od sebe.
P.P.S. Povej kje delaš, da vemo katerega podjetja se izogibat.
Zgodovina sprememb…
- spremenilo: Akira_ ()
kuall ::
Z žaljenjem nisem jaz začel. Vi ne znate debatirat normalno ampak imate čustvene izpade ob čist tehničnih temah. Čustvene debilkote težko gledam, zato se mi ne bomo več pogovarjali.
Akira_ ::
Z žaljenjem nisem jaz začel. Vi ne znate debatirat normalno ampak imate čustvene izpade ob čist tehničnih temah. Čustvene debilkote težko gledam, zato se mi ne bomo več pogovarjali.
Ljudje so ti dobronamerno želeli pomagat in ti podali tudi dobre primere.
Ti si pa pač žaljivo neumen.
Povej kje delaš, da se podjetja na široko ognemo.
Zgodovina sprememb…
- spremenilo: Akira_ ()
showsover ::
Kuall, ne obremenjuj se za tukajšnje žalitve; za močno izjavo moraš močno stati, ker izzivaš standarde, ki so bili sprejeti DOLGOOO nazaj. :-)
PrimoZ_ ::
Ta forum je samo tekmovanje, kdo bo znal bolje užalit. Beda. Prav, pa ne bom več pisal. Meni tekmovanje v tem, kako en druzga bolj užalit ni glih užitek.
Moderatorji: izgubili ste še enega člana, ker niste brisali žaljivih postov.
Ne morem verjet, da nam je uspelo :)
Upam, damo da je kaj bolj mož beseda kot Hipatij.
Lonsarg ::
Ma preko forumov je težko take zadeve, v živo takega ki ima priučene slabe prakse skoraj vedno uspem hitro udomačiti, žal velikokrat na ta način da tisti s temi slabimi praksami pride do spoznanja da nima dovolj znanja in sprejme boljše prakse brez da bi jih razumel :)
Kar je grdo v SQL standardu niso null values, grdo pa je defaultno handlanje le-teh v operacijah po mojem mnenju (posledica je da mora programer precej paziti na null value in se marsikomu radi zamerijo). Handlanje "null=null is true" kot ima C# bi bilo precej bolj domače. Sam take stvari ne moreš lih naknadno spremenit.
Kar je grdo v SQL standardu niso null values, grdo pa je defaultno handlanje le-teh v operacijah po mojem mnenju (posledica je da mora programer precej paziti na null value in se marsikomu radi zamerijo). Handlanje "null=null is true" kot ima C# bi bilo precej bolj domače. Sam take stvari ne moreš lih naknadno spremenit.
Zgodovina sprememb…
- spremenil: Lonsarg ()
Tody ::
Null ni nikoli null vsaj ne v sql ker analitično to pomeni da ni vrednosti je enako ni vrednosti, kar pa je nesmisel. Preskakovanje med tehnologijami je zajeban sam poglejte kaj vse pusti javascript pa...
WizzardOfOZ ::
Za datumska polja v bazah jaz tudi ne uporabljam null vrednosti. Vedno najmanjši ali največji datum, ki ga baza podpira.
Datum začetka je ponavadi 19000101, datum konca pa 99991231. To pa zato da se dajo datumi lepo sortirat. Pa vsem neznanim datumom že takoj v programih za insert določimm vrednost.
Null value pa uporabljam recimo za kake davčne številke ali kaj podobnega, da se izognem ničli (0) in da se lahko vprašam where polje is null. Ker nekdo ima lahko 6 avtov, nekdo nič avtov pa 2 kolesa, nekdo pa ni hotel dati podatka in tam vnesem null vrednost.
Datum začetka je ponavadi 19000101, datum konca pa 99991231. To pa zato da se dajo datumi lepo sortirat. Pa vsem neznanim datumom že takoj v programih za insert določimm vrednost.
Null value pa uporabljam recimo za kake davčne številke ali kaj podobnega, da se izognem ničli (0) in da se lahko vprašam where polje is null. Ker nekdo ima lahko 6 avtov, nekdo nič avtov pa 2 kolesa, nekdo pa ni hotel dati podatka in tam vnesem null vrednost.
Lonsarg ::
WizzardOfOZ je izjavil:
Za datumska polja v bazah jaz tudi ne uporabljam null vrednosti. Vedno najmanjši ali največji datum, ki ga baza podpira.Oh ja, realni spomini z takimi hacki. Tako bazo sploh ne moreš dati nevsebinskemu developerju da jo vzame kot osnovo in nekaj naredi, ker ga moraš prej tedne uvajat v vse take hacke v poljih. Na koncu je vse to fasala edina oseba ki je te hacka poznala, oziroma do neke mere sem se na te hacke privadil jaz da sem postal delno nadomestilo. Pa še to nism teh hackov imel v glavi ampak sem vsakič šel brskal po kodi za nazaj da sem se vsakič spomnil kake fore so (oziromas z get distinct in count sem nekako izluščil iz obstoječih podatkov kaj je mišljeno kot min in max).
Datum začetka je ponavadi 19000101, datum konca pa 99991231. To pa zato da se dajo datumi lepo sortirat. Pa vsem neznanim datumom že takoj v programih za insert določimm vrednost.
Zgodovina sprememb…
- spremenil: Lonsarg ()
WizzardOfOZ ::
Nočem nevsebinskega developerja. Oziroma jih v mojem poslu ne rabim.
Mi smo to dolocili skupaj za vse baze, da se datumi vedno pišejo. In res vsi developerji to upoštevajo, ker imaš potem vedno v polju vrednost. Sortiranje je pa izredno hitrejše.
Mi smo to dolocili skupaj za vse baze, da se datumi vedno pišejo. In res vsi developerji to upoštevajo, ker imaš potem vedno v polju vrednost. Sortiranje je pa izredno hitrejše.
Zgodovina sprememb…
- spremenilo: WizzardOfOZ ()
joze67 ::
OP: V bazi ne moreš imeti 'nič'. NULL nakazuje, da je tam prazno polje. [...] Ostali: če nimate pojma, bodite raje tiho.
OP bi moral objaviti vsaj shemo. Oziroma razložiti, kako ima organizirane podatke. Lahko da uporablja kako tabelo trojčkov (i, j, v), kjer je v vrednost v i-ti vrstici in j-tem stolpcu. V tem primeru lahko stremi za tem, da ima v bazi samo zapise, ki niso prazni.
Invictus ::
Ko nekdo v računalništvu reče, da se nekaj ne da, ali ne sme, se takoj ve, da se gre za levaka...
Če tako določiš, je lahko v polju NULL. In to ustrezno obdelaš. Če hočeš fiksno vrednost, jo določiš. Neka vrednost, ki pomeni da polje nima "vrednosti". Kar se nikoli ne pojavi v realnih podatkih...
Zapišeš v dokumentacijo in pri reviewih kode paziš, da se tega držijo... Case closed.
Vi da delate celo znanost iz tega...
A bodo pri tebi začeli
?
Če tako določiš, je lahko v polju NULL. In to ustrezno obdelaš. Če hočeš fiksno vrednost, jo določiš. Neka vrednost, ki pomeni da polje nima "vrednosti". Kar se nikoli ne pojavi v realnih podatkih...
Zapišeš v dokumentacijo in pri reviewih kode paziš, da se tega držijo... Case closed.
Vi da delate celo znanost iz tega...
Ta forum je samo tekmovanje, kdo bo znal bolje užalit. Beda. Prav, pa ne bom več pisal. Meni tekmovanje v tem, kako en druzga bolj užalit ni glih užitek.
Moderatorji: izgubili ste še enega člana, ker niste brisali žaljivih postov.
A bodo pri tebi začeli
? "Life is hard; it's even harder when you're stupid."
http://goo.gl/2YuS2x
http://goo.gl/2YuS2x
Zgodovina sprememb…
- spremenil: Invictus ()
Tody ::
Invictius upam da ne razvijaš kaj za avtomobilsko industrijo, ker potem bomo vsi najebal :)
Standardi so tam zato, da se jih upošteva, razen seveda če si Microsoft, pa še njega so na koncu pripeljali do tega da je treba to upoštevat. Je pa treba upoštevati seveda ali delaš nek kalkulator, ki ga bo uporabila samo tvoja mami ali pa nek reporting sistem za 500+ ljudi.
Standardi so tam zato, da se jih upošteva, razen seveda če si Microsoft, pa še njega so na koncu pripeljali do tega da je treba to upoštevat. Je pa treba upoštevati seveda ali delaš nek kalkulator, ki ga bo uporabila samo tvoja mami ali pa nek reporting sistem za 500+ ljudi.
Invictus ::
Ja, zato so standardi. jih pač prebereš in upoštevaš...
Drugače pa reporting za 500+ ljudi zgleda velik sam v Sloveniji.
V monitoringu infrastrukture in storitev pa komot uporabljaš NULL v bazi, pa ni problemov.
A zdaj se bo našel vsak iz ene industrije in težil s svojimi standardi.
Sicer pa, kaj ima sploh baza za počet v avtu?
Drugače pa reporting za 500+ ljudi zgleda velik sam v Sloveniji
.V monitoringu infrastrukture in storitev pa komot uporabljaš NULL v bazi, pa ni problemov.
A zdaj se bo našel vsak iz ene industrije in težil s svojimi standardi.
Sicer pa, kaj ima sploh baza za počet v avtu?
"Life is hard; it's even harder when you're stupid."
http://goo.gl/2YuS2x
http://goo.gl/2YuS2x
Tody ::
Null je cisto ok to se strinjamo?
V vseh industrijah.
Vrjetno je kaka,saj si zapisuje veliko podatkov al kaj?
V vseh industrijah.
Vrjetno je kaka,saj si zapisuje veliko podatkov al kaj?
SloKin ::
Invictus ::
Null je cisto ok to se strinjamo?
V vseh industrijah.
Vrjetno je kaka,saj si zapisuje veliko podatkov al kaj?
Ne. Null ni ok v vseh industrijah. Predvsem je slabo, če dobiš null pointer exception...
Predvsem je slabo, če tega ne znaš obdelati. Zajeb programerja...
Tipična napaka pri programiranju...
"Life is hard; it's even harder when you're stupid."
http://goo.gl/2YuS2x
http://goo.gl/2YuS2x
showsover ::
Tody ::
Tudi v SQL noben noče vidit NULL, ker to pomeni da je šlo nekaj narobe... Ampak kot je rekel Invictus... Lahko se pa mi v tej temi zmenimo da bo null zmeraj -300 :D
win64 ::
Null je cisto ok to se strinjamo?
V vseh industrijah.
Vrjetno je kaka,saj si zapisuje veliko podatkov al kaj?
Ne. Null ni ok v vseh industrijah. Predvsem je slabo, če dobiš null pointer exception...
Predvsem je slabo, da ne zaznaš napake ob nepravilnih vrednostih in posledično nepravilno obdeluješ podatke.
In exception je kar dobra rešitev za zaznavo napake.
showsover ::
Ne, to ne pomeni nujno, da je šlo karkoli narobe, le to, da pričakovan podatek ni bil na voljo v času vpisovanja iz kateregakoli razloga. Če bi želel uiber normalizirati (in v celoti odpraviti potrebo za NULL ne-vrednosti), bi šel na Jožetove triplete, kar prinese druge komplikacije in mislim, da se to najbolj uporablja v embedded sceni...
Če (z meritvami?) ugotoviš, da je potrebno nekje (recimo, performanse ali absurdno poenostavitev) namesto NULLa pač uporabiš konkretno dokumentirano vrednost, kar pa je nenavadna rešitev, verjetno sicer najlažja, ampak, če je toliko NULL, da že vpliva na performanse, pa nekaj res ni bilo v redu zmodelirano (ja, ja, legacy, jasno)... Možnost imaš sicer uporabiti order by dopolnilo, kam naj postavi NULL vrednosti (NULLS FIRST/LAST).
PS: Kuall se je čisto umaknil, mora dobiti debelejšo kožo ali pa navesti konkretne primere, ki podpirajo njegovo splošno izhodišče.
Če (z meritvami?) ugotoviš, da je potrebno nekje (recimo, performanse ali absurdno poenostavitev) namesto NULLa pač uporabiš konkretno dokumentirano vrednost, kar pa je nenavadna rešitev, verjetno sicer najlažja, ampak, če je toliko NULL, da že vpliva na performanse, pa nekaj res ni bilo v redu zmodelirano (ja, ja, legacy, jasno)... Možnost imaš sicer uporabiti order by dopolnilo, kam naj postavi NULL vrednosti (NULLS FIRST/LAST).
PS: Kuall se je čisto umaknil, mora dobiti debelejšo kožo ali pa navesti konkretne primere, ki podpirajo njegovo splošno izhodišče.
win64 ::
Ja, ampak ravno tako kot si pozoren na null, moraš biti pozoren na neko predefinirano konstanto. S tem, da če nisi pozoren na null bo najverjetneje nastala napaka med izvajanjem.
Se pa strinjam, da če želiš karkoli optimizirati, moraš včasih kaj narediti izven priporočil iz učbenikov. Važno je, da to res dobro dokumentirano in poskrbiš, da je čimmanj možnosti napačne interpretacije pri nadaljnji uporabi.
Se pa strinjam, da če želiš karkoli optimizirati, moraš včasih kaj narediti izven priporočil iz učbenikov. Važno je, da to res dobro dokumentirano in poskrbiš, da je čimmanj možnosti napačne interpretacije pri nadaljnji uporabi.
forest_guy ::
NULL vrednosti so v določenih primerih nujne in je po mojem mnenju bolje tako, kakor da polnimo neke "dummy" vrednosti. Vzemimo primer, da uporabnik v aplikacijo ni vnesel pogodbene vrednosti (ker to ni obvezen podatek). Če bi v takih primerih imeli nastavljeno default vrednost (npr. 0 ali -99), bi to bistveno pokvarilo povprečje, sumarno vrednost vseh pogodb itd. pri analitiki. Prav tako hitro dobimo seznam pogodb, kjer pogodbena vrednost dejansko ni definirana in jih ločimo od tistih, kjer je pogodbena vrednost = 0. V primeru datumskih podatkov pa so dummy vrednosti verjetno bolj smiselne (ker je praktično nemogoče, da bi bili dejanski datumi enaki dummy vrednostim - 1.1.1900 in 31.12.9999), temu ustrezno je tudi uporaba NOT NULL bolj smiselna.
Utk ::
ker je praktično nemogoče, da bi bili dejanski datumi enaki dummy vrednostim - 1.1.1900 in 31.12.9999
Če je nemogoče, še ne pomeni, da je koristno. Kaj boš v nekem poročilu napisal, da je bil nekdo rojen leta 9999, če ne veš kdaj? Boš napisal, da neka stvar traja do leta 9999, če nima datuma konca? Boš za vsako tako stvar pretvarjal v NULL? Boš to pretvarjal v prazen string že v bazi in ne (šele) na izpisu kar je nekako bolj pravilno?
To je morda koristno za tiste, ki tako delajo. Ne moreš pa tega ven poslat. In potem moraš zelo pazit preden take čudne vrednosti pošlješ nekomu.
forest_guy ::
ker je praktično nemogoče, da bi bili dejanski datumi enaki dummy vrednostim - 1.1.1900 in 31.12.9999
Če je nemogoče, še ne pomeni, da je koristno. Kaj boš v nekem poročilu napisal, da je bil nekdo rojen leta 9999, če ne veš kdaj? Boš napisal, da neka stvar traja do leta 9999, če nima datuma konca? Boš za vsako tako stvar pretvarjal v NULL? Boš to pretvarjal v prazen string že v bazi in ne (šele) na izpisu kar je nekako bolj pravilno?
To je morda koristno za tiste, ki tako delajo. Ne moreš pa tega ven poslat. In potem moraš zelo pazit preden take čudne vrednosti pošlješ nekomu.
Utk, Good point! Če nekaj nima datuma konca, je lahko podobno, kot če nima pogodbene vrednosti... se strinjam s tvojim komentarjem!
No, v mojem primeru, se o takšnih in drugačnih definicijah praznih vrednosti vselej dogovorimo z naročnikom na vsebinskih delavnicah, zato je tudi lahko od stranke do stranke zadeva različno implementirana. Vsaj po mojih izkušnjah je še najbolje, da to torej določijo vsebinski uporabniki, oni bodo tudi najbolje poznali uporabo podatkov v praksi.
no comment ::
forest_guy je izjavil:
V primeru datumskih podatkov pa so dummy vrednosti verjetno bolj smiselne (ker je praktično nemogoče, da bi bili dejanski datumi enaki dummy vrednostim - 1.1.1900 in 31.12.9999), temu ustrezno je tudi uporaba NOT NULL bolj smiselna.
Khm, vsi vemo, da se za to uporabljata 1.1.1753 in 31.12.999, če je že uporaba indexa na nullable koloni znanstvena fantastika v tem času in prostoru.
WizzardOfOZ ::
ker je praktično nemogoče, da bi bili dejanski datumi enaki dummy vrednostim - 1.1.1900 in 31.12.9999
Če je nemogoče, še ne pomeni, da je koristno. Kaj boš v nekem poročilu napisal, da je bil nekdo rojen leta 9999, če ne veš kdaj? Boš napisal, da neka stvar traja do leta 9999, če nima datuma konca? Boš za vsako tako stvar pretvarjal v NULL? Boš to pretvarjal v prazen string že v bazi in ne (šele) na izpisu kar je nekako bolj pravilno?
To je morda koristno za tiste, ki tako delajo. Ne moreš pa tega ven poslat. In potem moraš zelo pazit preden take čudne vrednosti pošlješ nekomu.
Ne boš pisal take cifre v poročilo. Prikazoval takih datumov ne boš.
Sta pa to pri nas (v naši firmi) uradno domenjena datuma za začetni in končni datum, če ni drugega podatka. In tudi ko iščeš tiste "brez datuma", samo vpišeš ali eno ali drugo številko in jih dobiš.
Zgodovina sprememb…
- spremenilo: WizzardOfOZ ()
Tody ::
Najprej naredijo takega z null pol pa dobijo nazaj da je tuki neki čudnega pa potem pripravijo ta pravega :)
Ales ::
WizzardOfOZ je izjavil:
ker je praktično nemogoče, da bi bili dejanski datumi enaki dummy vrednostim - 1.1.1900 in 31.12.9999
Če je nemogoče, še ne pomeni, da je koristno. Kaj boš v nekem poročilu napisal, da je bil nekdo rojen leta 9999, če ne veš kdaj? Boš napisal, da neka stvar traja do leta 9999, če nima datuma konca? Boš za vsako tako stvar pretvarjal v NULL? Boš to pretvarjal v prazen string že v bazi in ne (šele) na izpisu kar je nekako bolj pravilno?
To je morda koristno za tiste, ki tako delajo. Ne moreš pa tega ven poslat. In potem moraš zelo pazit preden take čudne vrednosti pošlješ nekomu.
Ne boš pisal take cifre v poročilo. Prikazoval takih datumov ne boš.
Sta pa to pri nas (v naši firmi) uradno domenjena datuma za začetni in končni datum, če ni drugega podatka. In tudi ko iščeš tiste "brez datuma", samo vpišeš ali eno ali drugo številko in jih dobiš.
In v čem je point dveh različnih? Da se ne da hkrati dobiti celega seznama?
A kuall pri vas dela?
WizzardOfOZ ::
Ales ::
Eden lepših filingov, profesionalno, mi je, ko zradiram kak dolgotrajen tehnični dolg. Kaj kar se vleče, uporablja, patcha, šlepa, popravlja, trpi in imaš vedno tisti prikriti občutek, da ni ok. In potem se enkrat končno znebiš...
Blissss
Blissss
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Registrska označba NULL lastniku povzroča težave in stroškeOddelek: Novice / Ostale najave | 5975 (2874) | MrStein |
| » | SQL vprasanje (strani: 1 2 )Oddelek: Programiranje | 7898 (4577) | BivšiUser2 |
| » | PostgreSQL pomočOddelek: Programiranje | 2370 (1863) | Mato989 |
| » | Nova različica podatkovne baze PostgreSQL 9.5 prinaša obilico novosti (strani: 1 2 )Oddelek: Novice / Ostala programska oprema | 16464 (13330) | McAjvar |
| » | MS Access (strani: 1 2 )Oddelek: Programiranje | 7075 (5133) | travica |