En blogg om teknologiledelse

Jeg er det svenskene kaller en «prylbög«, det vil si en person med utpreget sans for duppeditter. Siste tilskudd er radioen Tivoli Model DAB som nå står plassert på nattbordet. Prisen er stiv, men lyden er god og designet glimrende.

Det neste på denne stammen blir en ekstrahøyttaler med vekkerklokke til husfruen, Tivoli Model CD, samt Tivoli Model Subwoofer. :-)

I drøyt to måneder har jeg benyttet meg av webtjenesten LinkedIn. Kort fortalt er LinkedIn et ypperlig verktøy for å administrere både ditt faglige og sosiale kontaktnettverk.

LinkedIn beskriver seg selv slik:

LinkedIn is an online network of more than 5.2 million experienced professionals from around the world, representing 130 industries.

When you join, you create a profile that summarizes your professional accomplishments. Your profile helps you find and be found by former colleagues, clients, and partners. You can add more connections by inviting trusted contacts to join LinkedIn and connect to you.

Your network consists of your connections, your connections’ connections, and the people they know, linking you to thousands of qualified professionals.

Selv har jeg for øyeblikket ti kontakter. Via mine kontakter har jeg mer enn 300 kontakter, og via deres kontakter igjen over 13 400 kontakter.

Via nettverket får man informasjon om ledige stillinger, kan tilby stillinger, utveksling av kunnskap, kunder og andre forretningsmessige tjenester.

Om ønskelig kan du komme i kontakt med meg via min LinkedIn-profil.

Fra tid til annen får jeg spørsmål om hvordan søking i databaser fungerer, for eksempel i søkemotorer. La det være sagt med en gang: Dette er et svært omfattende fagområde, og jeg er slett ingen guru på området. Hos min arbeidsgiver har vi ansatte som er sertifiserte på området, og som kun driver med databaser, det være seg installasjon, oppsett, drift og ikke minst optimalisering. Jeg er ikke en av de, men vil allikevel besvare det mest banale i denne artikkelen.

Innholdet i en database

En database består av minst en tabell, som igjen består av minst en kolonne og en post. Et eksempel kan være et personregister, illustrert med en tabell vi kaller «personregister», slik:

Indekser

Når man skal gjøre søk i denne tabellen, vil det ved første øyekast være naturlig å lete igjennom hver eneste post i tabellen, for så å sjekke hvilke poster som matcher søkekriteriet. Det sier seg selv at dette vil ta uholdbart lang tid dersom tabellen inneholder mange poster. Derfor oppretter vi det vi kaller en indeks. En indeks kan kort beskrives som en innholdsfortegnelse, og opprettes som en egen, frittstående tabell i databasen, slik:

Et søk i en tabell uten indeks kalles «Table Scan» fordi søket ikke utføres mot en indeks (altså i indeks-tabellen), men i stedet går igjennom hver eneste post i tabellen.

Det opereres også med såkalte unike indekser. En unik indeks kun vil forekomme i én post i tabellen. I eksemplet over vil «Personnr» typisk være en unik indeks, da personnummeret er unikt for hver person. Forskjellen er at databasen vil stoppe søket i en unik indeks, når søkestrengen treffes, mens den vil søke igjennom hele indeksen i en vanlig indeks. En indeks kobles til en kolonne i hver tabell, omtrent slik:

Det kan opprettes en eller flere indekser per tabell, men det er viktig at designeren og utvikleren ikke oppretter for mange og store indekser, da dette fort kan få motsatt effekt, og går ut over hastigheten. Eksempelvis kan det i tillegg til «Personnr» kan det for eksempel opprettes en indeks på «Fornavn», slik:

Vi sitter da igjen med selve tabellen og to indekser, slik:

På denne måten kan man legge til en indeks for hver kolonne i tabellen. Bakdelen er at også indeksene må vedlikeholdes. Det vil si at hvis programvaren skal gjøre en endring i en post, for eksempel endre etternavnet til Kari Nordmann til Hansen når hun gifter seg, vil databasen måtte skrive til samtlige indekstabeller, og således gå kraftig ut over hastigheten.

Søk

Et søk sendes til databasen fra programvarelaget via forretningslaget. I databasen vil et søk bli utført som en SQL-spørring, for eksempel:

1. SELECT * FROM personregister;

Søket vil returnere hele tabellen, mens et begrenset søk, for eksempel på personnummer, kun vil returnere de utvalgte data.

Dette er som nevnt en ekstrem forenkling, men det er prinsippet som er poenget.