Waar gebruik je de IP-adressen voor? En zijn deze noodzakelijk?

Als je namelijk een oplossing hebt waarbij je niet afhankelijk bent van IP-adressen, dan heb je dit probleem in eerste instantie niet.

En hoe speelt snelheid hier een (cruciale?) rol? Je kunt toch gewoon een index aanmaken op een kolom?

Als je de MySQL page er op na lijst is de functie zoals jij deze aangeeft voor beide een goede combo voor te maken.

Linkje:
https://dev.mysql.com/doc/refman/5.7…tion_inet6-aton

Op die pagina:

SELECT INET6_NTOA(INET6_ATON('fdfe::5a55:caff:fefa:9089'));
        -> 'fdfe::5a55:caff:fefa:9089'


SELECT INET6_NTOA(INET6_ATON('10.0.5.9'));
        -> '10.0.5.9'


SELECT INET6_NTOA(UNHEX('FDFE0000000000005A55CAFFFEFA9089'));
        -> 'fdfe::5a55:caff:fefa:9089'


SELECT INET6_NTOA(UNHEX('0A000509'));
        -> '10.0.5.9'

Mocht je er maar een veld voor hebben kan je vrij gemakelijk een CASE WHEN statement invoeren. En dat zou ook niet hoeven:

SELECT HEX(INET6_ATON('IP'));


SELECT INET6_NTOA(UNHEX('IP'));

Kan je de IP's als HEX opslaan scheelt ook weer ruimte in je database. Wil je het plain op slaan dan verwijder je de HEX / UNHEX.
Echter zal je altijd met een INT of een varbinary field moeten werken. Met hex values kan je iets makkelijker overweg.

Overigens een index maken op een IP field lijkt me niet echt de meest slimme keus in je database design. Zou ik zelf eerder voor een foreign key relatie met een andere tabel maken (mocht het IP uniek moeten zijn per user bijvoorbeeld). Of een clusted index maken in geval de tabel op zich zelf moet staan.

varbinary is een algemeen opslag veld zolang je er geen index op gaat zetten ga je geen performance issue's krijgen. Then again als je er wel een index op zet en dan een clusted dan zal je performance issues never nooit niet merken. (Tot je over de 50mil+ gaat dan wellicht een 0.1s delay).

Het gaat vooral om je query die er omheen zit wat de snelheid bepaald van de query of er en een table scan uitgevoerd moet worden of niet. Dus het zal heel erg afhangen ook van de rest van je DB hoe de performance zal zijn.

"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.

Proof of concept / test.

<?php
ini_set('display_errors', 'stdout');
error_reporting(E_ALL);


header('Content-Type: text/html; charset=UTF-8');


function escape($in) {
    return htmlspecialchars($in, ENT_QUOTES, 'UTF-8');
}


// @see http://php.net/manual/en/function.inet-ntop.php#117398
// PHP equivalent of MySQLs INET6_ATON(), because  inet_ntop() isn't apparently
/**
* Convert a MySQL binary v4 (4-byte) or v6 (16-byte) IP address to a printable string.
* @param string $ip A binary string containing an IP address, as returned from MySQL's INET6_ATON function
* @return false if not valid.
*/
function inet6_ntop($ip) {
    $l = strlen($ip);
    if ($l == 4 or $l == 16) {
        return inet_ntop(pack('A' . $l, $ip));
    }
    return false;
}
?>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>IP test</title>
</head>


<body>
<?php
$db = new mysqli('127.0.0.1', 'test', 'test', 'test');
$db->set_charset('utf8mb4');


$db->query("CREATE TABLE IF NOT EXISTS `test_ip` (
  `ipt_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `ipt_ip` varbinary(16) NOT NULL,
  PRIMARY KEY (`ipt_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4");


// https://www.randomlists.com/ip-addresses
$testIps = array(
    '42a6:4dff:28a7:c07d:3a32:97d8:369b:7277',
    'dc4c:5486:e:3321:caa3:4b09:6dfa:9f7b',
    'e2dc:60f1:43b7:3e3b:a6ad:9423:af5d:68ab',
    'fb6e:a7ef:4e3e:75ce:903b:c444:1ebc:babf',
    'aaa7:bf2a:b443:9fa9:72ee:67de:d1:8805',
    '5894:4879:4a27:dd5a:661c:9906:3ced:5163',
    '1eb:d630:692a:4e0f:ac14:4bfe:bc87:92d6',
    '68f4:1479:3615:353:f70b:7421:12f1:df62',
    'cda0:b4fe:ff76:a8ac:94de:5a91:b1c4:4633',
    '7c0a:3f82:5425:3a18:8cfd:8d03:ecb5:f9b1',
    '3bf:52c8:b5be:bd43:25c2:43fc:b22d:64e3',
    '3218:5c:4250:666b:25d:cb1:f2b0:6774',
    '252.228.69.200',
    '111.204.105.216',
    '182.170.251.175',
    '161.210.254.48',
    '69.176.138.182',
    '200.139.220.243',
    '67.95.35.174',
    '229.235.136.200',
    '151.68.1.236',
    '134.112.54.29',
    '10.56.42.115',
    '203.132.92.142',
);
$db->query('TRUNCATE test_ip');
foreach ($testIps as $ip) {
    // unpacked --> packed, store in DB in packed form in VARBINARY(16)
    $packedIp = inet_pton($ip); // already compatible with MySQLs INET6_NTOA()


    $db->query(
        "INSERT INTO test_ip (ipt_ip) VALUES (
            '".$db->real_escape_string($packedIp)."'
        )"
    );


    // packed --> unpacked, only for display purposes (human readable form)
    $unpackedIp = inet6_ntop($packedIp);


    $ok = $ip == $unpackedIp;


    echo $ip;
    ?> <b style="color: #<?php echo ($ok ? '00cc00' : 'cc0000') ?>;"><?php
    echo ($ok ? '' : 'NOT ') ?>OK</b><hr><?php
}
$res = $db->query(
    'SELECT ipt_ip AS packed,
    INET6_NTOA(ipt_ip) AS unpacked
    FROM test_ip'
);
while ($row = $res->fetch_assoc()) {
    $unpackedInSQL = $row['unpacked'];
    $unpackedInPHP = inet6_ntop($row['packed']);
    echo ($unpackedInSQL == $unpackedInPHP ? 'ok' : 'NOT ok').'<hr>';
}
?>[end]
</body>
</html>

Zolang je in de DB enkel werkt met de (rauwe) binaire variant kun je e.e.a. makkelijk optimaliseren.
Als je iets dan toch in human readable form moet weergeven dan regel je dat aan de PHP-zijde met bovenstaande custom functie (of in een MySQL console met INET6_NTOA()).

EDIT: codevoorbeeld uitgebreid met database.

Sorry @Bedrijfsportaal maar Fangor is kinderachtig?
Diegene heeft u geholpen, heeft een boek geschreven over wat je kan doen, voorbeeldcode gegeven,...
Dus je zou juist dankbaar moeten zijn en zeker niet zo bot reageren. Door zo bot te reageren ben jij hier het kind ;).

Citaat van Bedrijfsportaal

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.

Citaat van Bedrijfsportaal

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

K bye.