[SQL] IP-adressen

    ICTscripters maakt gebruik van cookies. Door het gebruiken en browsen naar onze site gaat je automatisch akkoord met het gebruik van cookies. Klik hier voor meer informatie

    • FangorN wrote:

      "Hoi ik wil niets uitleggen over mijn probleem maar ik wil wel de beste oplossing, kan iemand mij helpen?"

      Wat bedoel je met "verwerken" en hoe vaak gebeurt dit? Als het niet zo vaak voorkomt dat gegevens worden ingevoerd dan mogen deze toevoeg-operaties best wat duurder zijn. Als deze gegevens vervolgens heel vaak worden opgevraagd is het belangrijk dat deze snel uitgelezen kunnen worden.

      Vervolgens bepaalt de manier van gebruik van deze IP's hoe je deze het beste kunt optimaliseren, hier is geen universeel recept voor.

      Oftewel: een optimale afstemming van tabellen hangt van het gebruik af (wat doe je met deze informatie), en dit wordt weer bepaald door het gedrag / de werking van de applicatie (hoe gebruik je deze in je applicatie)... waar jij niets over wilt vertellen. Dat wordt dan knap lastig.

      On a side note: functies (in MySQL) toepassen op geïndexeerde kolommen, ik denk niet dat dat de snelheid ten goede komt (edit: als je dat in condities gebruikt, zou dat dan niet inhouden dat er toch eerdergenoemde tablescans worden uitgevoerd omdat gekeken moet worden of het resultaat van het toepassen van zo'n functie het gewenste resultaat oplevert?). Wat je wel zou kunnen doen is deze vertalingen uitvoeren in PHP, en zo wegschrijven in de database, en vervolgens zou je queries kunnen uitvoeren op deze geëncodeerde (en geïndexeerde) kolommen. Maar hier geldt weer dat dit sterk afhangt van hoe je deze data gaat gebruiken.

      Misschien is het voornaamste probleem wel dat je meet met twee maten, zoals @Patrick aangeeft kan INET6_ATON(expr) hier uitkomst bieden. Voor het terugvertalen in PHP zijn hier opties voor (blijkbaar is inet_ntop() (PHP) niet compatibel met INET6_ATON() (MySQL)). Ik zou dan denk ik wel deze functies alleen aan de PHP-zijde gebruiken, en het gebruik van functies in MySQL -in ieder geval bij het opvragen van informatie- vermijden.

      tl;dr omdat je niet uitlegt hoe iets zou moeten werken, is het ook vrij onmogelijk om hier een optimale aanpak bij te verzinnen. Mogelijk heb je toch iets aan bovenstaande opmerkingen.
      Ik heb geen probleem ik heb een vraag, ik hoef daarvoor geen details te geven over een project. Het gaat om het type opslag en of ik hiermee performance verlies bij meerdere data verwerking. Dat jij jezelf zo kinderachtig opstelt zegt genoeg over jou, ik weet voldoende stel me vragen voortaan ergens anders.


      Onderwerp mag gesloten worden, bedank.
    • Bedrijfsportaal wrote:

      Ik heb geen probleem ik heb een vraag, ik hoef daarvoor geen details te geven over een project. Het gaat om het type opslag en of ik hiermee performance verlies bij meerdere data verwerking.
      Zie mijn laatste reply, daarin zit een hoop voorbeeldcode waarmee je wel vooruit kunt denk ik.

      Met de reactie daarvoor wilde ik alleen aangeven dat het moeilijk (zo niet onmogelijk) is om een beeld te vormen van een optimale aanpak voor het gevraagde, en ook om de absurditeit van hoe je dit vraagt te benadrukken. Je geeft een enkel puzzelstuk, en verwacht dan dat we kunnen vertellen hoe de hele legpuzzel er uit dient te zien?

      Daarna probeer ik die stelling verder te onderbouwen door aan te geven dat de database (wat in feite het fundament vormt voor je applicatie) in dienst staat van de applicatie, en dus hier ook op moet zijn afgestemd.

      Als je niet uitlegt hoe de applicatie (technisch) werkt, dan wordt het ook vrij lastig om een database op de goede manier in te richten.

      Met mijn "kinderachtige opstelling" hield ik in zekere zin ook een spiegel voor, maar dat is je waarschijnlijk ontgaan. Je het over een "uniek concept" alsof je the next best thing since sliced bread hebt uitgevonden. Als je dan toch op de kip met de gouden eieren denkt te zitten, waarom stap je dan niet naar een bureau om dat concept uit te werken als het je aan technische kennis ontbreekt? Ah, I see.

      Bedrijfsportaal wrote:

      Dat jij jezelf zo kinderachtig opstelt zegt genoeg over jou, ik weet voldoende stel me vragen voortaan ergens anders.
      K bye.