Hopp til innhold

Da jeg gikk fra Delphi til C# ble jeg ikke overbegeistret over behovet for string.IsNullOrEmpty(myString) hver gang man skulle sjekke for tom streng. Jeg forstår at det kan bety en forskjell i den tekniske implementasjonen, men jeg forstår ikke hvorfor vi må brys med dette. Temaet har vært diskutert gang på gang, og det ser ut til at de fleste utviklere støtter idéen om at en tom streng faktisk ikke er det samme som en NULL-verdi.

jeg er uenig, av flere grunner:

  • En streng er den eneste datatypen som faktisk har en naturlig NULL-verdi - en tom streng. Når du kan oppgi mellomnavn, betyr det "ingen verdi" om du lar feltet stå åpent.
  • En stor databaseprodusent - Oracle - håndterer tom streng som NULL uten at dette er problematisk for en verden av RDBMS-utviklere, og programmeringsspråket Delphi Pascal (Versjon 2 ->) implementerer en tom streng som en NULL-peker under panseret uten at særlig mange utviklere har vært klar over det. jeg har aldri hørt noen klage på dette.
  • For andre datatyper kan en brukerkontroll lett vise en NULL-verdi: En  checkbox gråes ut, en radiogruppe har ingen selektert, et tomt numerisk felt. Hvordan ville du representert en NULL-verdie i en tekstboks ? Vise en grået  <null> eller <empty> når verdien faktisk er NULL, og blank hvis verdien er en tom streng ? Lykke til med å forklare forskjellen til brukere...

Det eneste tilfellet hvor du faktisk må skille er i databasekolonner med UNIQUE constraint; Men her vil håndteringen av tom streng som NULL løse problemet.

EN slik under-panseret-håndtering som finnes i både Oracle og Delphi fører selvsagt med seg noen ekstra operasjoner her og der (=flere klokketikk), men jeg tror dette i de fleste tilfelle vil være fønskelig.

Mens vi snakker om rare tema i IT-verdenen - visste du at i Firebird database  er 0<>-0 ?

Ha en god dag !

I mitt første år som systemutvikler diskuterte vi om det ville være mulig å skrive en algoritme for sidelayout i aviser, og da spesielt for å plassere annonser innimellom journalistisk innhold. Reklameplass ble solgt for en spesiell seksjon av publikasjonen, som "sportssidene", "nyhetsseksjonen" o.s.v.. … fortsett å lese «Algoritme for best utnyttelse basert på tilfeldighet»

For lenge siden, før webapplikasjoner, oppsto idéen om 3-lags applikasjoner. Idéen var ganske enkel og innevarslet et paradigmeskifte for applikasjonsstruktur. Dette var i  Client/Server - æraen, husk det, systemer typisk bygget som … fortsett å lese «3-lags arkitektur – hva var galt med modellen ?»

'Arkitekt'-begrepet er vanskelig å beskrive siden det finnes mange varianter der ute - fellesnevneren er at det kan inkludere alle stadier i utviklingsprosessen unntatt den faktiske implementasjonen. I små proskjekt eller organisasjoner vil arkitekten gjøre alt fra å avklare funksjonalitet med systemeier til å beskrive teknisk … fortsett å lese «Hvorfor ‘arkitekt’ er en misvisende betegnelse i systemutvikling»

Når jeg snakker om 'generalisering', mener jeg det å trekke det generelle ut fra det spesielle, som å håndtere den visuelle representasjonen av en 'faktura' som et 'dokument' og en 'ansatt' som en 'person'. … fortsett å lese «Hvorfor generalisere systemer?»

To SCRUM team utvikler separate deler av et system, inkludert et API for kommunikasjon mellom dem. De jobber smidig, så de ønsker å kunne gjøre raske endringer - "omfavn forandring" - men hva med endringer i APIet når dette først er definert? … fortsett å lese «API og smidig utvikling»

Strukturen i en relasjonsdatabase (RDBMS) har som ett av flere prinsipper at data ikke skal dupliseres. Om en database inneholder personopplysninger, ligger disse i en egen tabell og man trenger dermed ikke å endre navn i alle oppføringer i databasen om et "medlem" i databasen skifter navn. Her ligger det vakre i RDBMS'er: Endre navnet i én rad, og alle datauttrekk benytter dette navnet i ettertid. … fortsett å lese «Tidsakse i relasjonsdatabaser: Ren Ondskap»

Relasjonsdatabaser (RDBMS) strukturerer data som relasjoner, hvor data er delt opp i separate tabeller og linkes sammen. Jeg skal ikke gå gjennom hele teorien her, les evt. denne artikkelen for bakgrunnskunnskap. … fortsett å lese «Normalisering av relasjonsdatabaser – Persondata»