[db] efficientie

[Verwijderd]

Ik moet een server maken waarbij een databse bepaald of een client connectie mag maken, hiervoor moeten 2 dingen worden bijgehouden nl. mag een bepaald Ip adres verbinding maken en of het maximum aantal verbindingen voor dit Ip adres reeds is bereikt. Tevens dient per connectie specifieke informatie worden bijgehouden in de database. Ik had zelf de volgende oplossing

Client
- ID as autonummering (prim. sleutel)
- IpAddress as string
- MaximumConnections as integer
- Overige Info

Connection
- ID as autonummering (prim. sleutel)
- ClientID as integer
- Overige Info

De velden Client.ID en Connection.ClientID zijn dus gelinkt. Ik dacht zelf echter dat de volgende oplossing ook mogelijk is (IpAddress kan ook als primaire sleutel in mijn model functioneren):

Client
- IpAddress as string (prim. sleutel)
- MaximumConnections as integer
- Overige Info

Connection
- ID as autonummering (prim. sleutel)
- IpAddress as string
- Overige Info

Nu zijn de velden Client.IpAddress en Connection.IpAddress gelinkt.

Voordeel:
- Kleiner aantal velden
Nadeel:
- Connection heeft een "zwaarder" veld (string tov. integer)

Mijn vraag is:
Wat weegt zwaarder?

[Janoz]

IP adres kun je ook heel simpel opslaan in een 32-bit integer. Sterker nog, het IS een 32 bit integer. Het wordt alleen met die puntjes geschreven omdat mensen het hexadecimale stelsel zo lastig vinden en waneer dit getal decimaal geschreven zou worden het berekenen van maskers zo lastig zou worden

[Verwijderd]

Ik voer het echter als string in (tekstveld) zou een omrekenfunctie dan wel zo efficient zijn?

[ACM]

Tuurlijk, stringbewerkingen zijn altijd veel zwaarder dan die enkele omzettingen van je integer van tekst naar integer.

Postgresql heeft er trouwens speciale datatypen voor waarmee je veel eenvoudiger met ip's kan werken enzo. (bepalen of iets in een domein ligt, etc met een simpele vergelijkings operator)

[jochemd]

Voor wat er zwaarder weegt werkt maar 1 ding: testen. Mocht je trouwens de keuze hebben dan werkt het IP datatype van PostgreSQL wel erg lekker. En als je voor de omzetting naar een 32 bit integer gaat, denk dan wel even aan het verschil tussen een signed en een unsigned integer.