SUBSTR.... hoe zit het nu eigenlijk?
soms zie je door het bomen het bos niet meer.... en als je zoekt op wat je denkt nodig te heb verzuip je in alle goede bedoelde antwoorden en komt je verder en verder van de oorspronkelijke vraag weg. Zo ook heb ik het dit keer met de SUBSTR. Waar ik naar op zoek vind (maar niet kan vinden van de overweldigende repsonses weet je niet wat de juiste is).. Ik wil gedeelte van string die tussen twee gelijke karakters staan halen.
Laten we zeggen dat dit de string is : Level 1:Level 2:Level 3:Level 4:Level 5
Nu heb ik alleen Level 2 nodig. Zou een stuk eenvoudiger zijn als de lengtes van de levels gelijk waren. Dan zou kan ik een begin positie opgeven en de lengte maar dat is dus niet zo.. De lengte varieert dus.
De string is een waarde van een veld.
ik had ongeveer het volgende bedacht om te gebruiken :
Code (php)
1
SUBSTR(Z_ORG_DN, CHARINDEX(':', Z_ORG_DN) + 1, LEN(Z_ORG_DN)) AS Divisie
Maar dat werkt dus niet.. Krijg dan de foutmelding: Warning: mysqli_num_rows() expects parameter 1 to be mysqli_result, boolean given in
Mijn volledige code is:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
<?php
$sqlUitlezen = mysqli_query($connection,
$sql = "SELECT
idm_doelsysteem.MSKEYVALUE_DOELSYSTEEM,
idm_doelsysteem.ABC_PLATFORM,
idm_doelsysteem.ABC_DOMAIN,
idm_doelsysteem.ABC_REF_OU,
idm_doelsysteem.ABC_AUT_DEFAULT_OWNER,
idm_doelsysteem.Z_SYSTEM_RECONCILE_SOLL_ACCOUNTS,
idm_doelsysteem.Z_SYSTEM_RECONCILE_REMOVE_IST_ASSIGNMENTS,
idm_doelsysteem.Z_SYSTEM_RECONCILE_TIMESTAMP,
idm_ou.MSKEYVALUE_OU,
idm_ou.DISPLAYNAME,
SUBSTR(idm_ou.Z_ORG_DN, CHARINDEX(':', idm_ou.Z_ORG_DN) + 1, LEN(idm_ou.Z_ORG_DN)) AS Divisie
FROM idm_doelsysteem
INNER JOIN `idm_ou` ON idm_doelsysteem.ABC_REF_OU = idm_ou.MSKEYVALUE_OU
ORDER BY idm_doelsysteem.ABC_REF_OU ASC");
$sqlAantal = mysqli_num_rows($sqlUitlezen);
echo '<table border="0" rules="rows">';
echo ' <tr>';
echo ' <td colspan="12"><font size="5">Doelsystemen</font></td>';
echo ' </tr>';
echo '<tr>';
echo '<td><h6><b>UNIEK KENMERK</b></h6></td>';
echo '<td> </td>';
echo '<td><h6><b>PLATFORM</b></h6></td>';
echo '<td> </td>';
echo '<td><h6><b>DOMEIN</b></h6></td>';
echo '<td> </td>';
echo '<td><h6><b>DIVISIE EIGENAAR</b></h6></td>';
if ($sqlAantal > 0){
while ($sqlData = mysqli_fetch_assoc($sqlUitlezen)){
echo '<tr>';
echo '<td><h6>'.$sqlData['MSKEYVALUE_DOELSYSTEEM'].'</h6></td>';
echo '<td> </td>';
echo '<td><h6>'.$sqlData['ABC_PLATFORM'].'</h6></td>';
echo '<td> </td>';
echo '<td><h6>'.$sqlData['ABC_DOMAIN'].'</h6></td>';
echo '<td> </td>';
echo '<td><h6>'.$sqlData['DISPLAYNAME'].' ('.$sqlData['ABC_REF_OU'].')</h6></td>';
echo '</tr>';
}
echo '</table>';
echo '<hr style="margin:5px 0 5px 0;">';
echo '<h5>Ik heb '.$sqlAantal.' doelsystemen gevonden die op IDM zijn aangesloten</h5>';
}else{
echo '<center><a href="javascript:javascript:history.go(-1)"><img src="../img/no-data.png"></a></center>';
}
?>
$sqlUitlezen = mysqli_query($connection,
$sql = "SELECT
idm_doelsysteem.MSKEYVALUE_DOELSYSTEEM,
idm_doelsysteem.ABC_PLATFORM,
idm_doelsysteem.ABC_DOMAIN,
idm_doelsysteem.ABC_REF_OU,
idm_doelsysteem.ABC_AUT_DEFAULT_OWNER,
idm_doelsysteem.Z_SYSTEM_RECONCILE_SOLL_ACCOUNTS,
idm_doelsysteem.Z_SYSTEM_RECONCILE_REMOVE_IST_ASSIGNMENTS,
idm_doelsysteem.Z_SYSTEM_RECONCILE_TIMESTAMP,
idm_ou.MSKEYVALUE_OU,
idm_ou.DISPLAYNAME,
SUBSTR(idm_ou.Z_ORG_DN, CHARINDEX(':', idm_ou.Z_ORG_DN) + 1, LEN(idm_ou.Z_ORG_DN)) AS Divisie
FROM idm_doelsysteem
INNER JOIN `idm_ou` ON idm_doelsysteem.ABC_REF_OU = idm_ou.MSKEYVALUE_OU
ORDER BY idm_doelsysteem.ABC_REF_OU ASC");
$sqlAantal = mysqli_num_rows($sqlUitlezen);
echo '<table border="0" rules="rows">';
echo ' <tr>';
echo ' <td colspan="12"><font size="5">Doelsystemen</font></td>';
echo ' </tr>';
echo '<tr>';
echo '<td><h6><b>UNIEK KENMERK</b></h6></td>';
echo '<td> </td>';
echo '<td><h6><b>PLATFORM</b></h6></td>';
echo '<td> </td>';
echo '<td><h6><b>DOMEIN</b></h6></td>';
echo '<td> </td>';
echo '<td><h6><b>DIVISIE EIGENAAR</b></h6></td>';
if ($sqlAantal > 0){
while ($sqlData = mysqli_fetch_assoc($sqlUitlezen)){
echo '<tr>';
echo '<td><h6>'.$sqlData['MSKEYVALUE_DOELSYSTEEM'].'</h6></td>';
echo '<td> </td>';
echo '<td><h6>'.$sqlData['ABC_PLATFORM'].'</h6></td>';
echo '<td> </td>';
echo '<td><h6>'.$sqlData['ABC_DOMAIN'].'</h6></td>';
echo '<td> </td>';
echo '<td><h6>'.$sqlData['DISPLAYNAME'].' ('.$sqlData['ABC_REF_OU'].')</h6></td>';
echo '</tr>';
}
echo '</table>';
echo '<hr style="margin:5px 0 5px 0;">';
echo '<h5>Ik heb '.$sqlAantal.' doelsystemen gevonden die op IDM zijn aangesloten</h5>';
}else{
echo '<center><a href="javascript:javascript:history.go(-1)"><img src="../img/no-data.png"></a></center>';
}
?>
Ben in deze ook even de klust aan het kwijtraken.
Quote:
Warning: mysqli_num_rows() expects parameter 1 to be mysqli_result, boolean given in
.. dan is enige foutafhandeling met mysqli_error(..) zeker wel prettig.
En nog een tip: echo-putten met lappen HTML kan je ook omzeilen door dit buiten een PHP-blok te plaatsen, en de variabelen en constantes even tussen PHP-tags te plaatsen.
Adoptive Solution op 11/08/2019 15:47:14:
hoi Adoptive Solution,
Dit kwam ik inderdaad ook al tegen in een eerdere post.. maar kwam er niet meer uit.
Leuk dat alle levels dan onder elkaar worden weergegeven maar is niet helemaal wat ik zoek.
Ik hoef alleen Level 2 te echoën.... de overige levels mogen in dit geval komen te vervallen. en dat is niet wat me tot nu toe gelukt is... zal wel eenvoudig zijn.. Maar is dit niet alles met wat je weet ;-)
Toevoeging op 11/08/2019 16:07:02:
- Ariën - op 11/08/2019 15:57:13:
En als je zulke errors krijgt:
.. dan is enige foutafhandeling met mysqli_error(..) zeker wel prettig.
En nog een tip: echo-putten met lappen HTML kan je ook omzeilen door dit buiten een PHP-blok te plaatsen, en de variabelen en constantes even tussen PHP-tags te plaatsen.
Quote:
Warning: mysqli_num_rows() expects parameter 1 to be mysqli_result, boolean given in
.. dan is enige foutafhandeling met mysqli_error(..) zeker wel prettig.
En nog een tip: echo-putten met lappen HTML kan je ook omzeilen door dit buiten een PHP-blok te plaatsen, en de variabelen en constantes even tussen PHP-tags te plaatsen.
wat is een echo-put?????
ik ken er maar eentje en als je daar in roep "Hoe heet de koning van wezel......" ;-)
Verder kan je met $levels[1] je tweede element met Level 2 oproepen. Die print_r() is overigens puur voor testen bedoeld om je boom van je array te bekijken.
Gewijzigd op 11/08/2019 16:12:46 door - Ariën -
Direct in de SQL query:
Code (php)
1
SUBSTRING_INDEX(SUBSTRING_INDEX(idm_ou.Z_ORG_DN,':',2),':',-1) AS Divisie
(eerst knippen tot de 2e ':', dan alleen het stuk vanaf de laatste ':' = enkel het 2e level)
Of achteraf in de PHP (ala oplossing Adaptive):
Code (php)
1
$divisie = explode(';',$sqlData['Z_ORG_DN'])[1] ?? null;
(index 1 = 2e level; die "?? null" zorgt ervoor dat er geen foutmelding komt als er minder dan 2 levels zijn)
Gewijzigd op 11/08/2019 16:16:55 door Rob Doemaarwat
Die SUBSTRING opnemen in mijn SQL query levert precies op wat ik nodig heb. Mijn dank ik wederom groot..
Complmenten naar jullie allemaal hoor dat jullie dit allemaal kunnen bedenken zeg :-) of is dit gewoon 'n kwestie van vlieguren?
Rob Doemaarwat op 11/08/2019 16:14:49:
Of achteraf in de PHP (ala oplossing Adaptive):
Code (php)
1
$divisie = explode(';',$sqlData['Z_ORG_DN'])[1] ?? null;
Dirk Huizinga op 11/08/2019 16:41:30:
Thnx Rob.... die Explode variant, zal ik vermoedelijk wel iets niet goed mee doen... ongetwijfeld.. Maar daar krijg ik geen resulaat.. Geen foutmelding maar ook geen waardes..
Bij Rob zal ';' wel ':' moeten zijn.
Gewijzigd op 11/08/2019 17:28:25 door - SanThe -
beide methodieken werken
Elke keer als ik dit soort constructies zie dan begint het bij mij een beetje te jeuken:
Code (php)
1
Level 1:Level 2:Level 3:Level 4:Level 5
Laten we los van wat je hiermee precies wilt doen eerst eens een analyse maken van deze bovenstaande constructie.
Allereerst: is deze echt nodig? Je bent bezig in een database. Een database is een plek waar je op een gestructureerde manier informatie opslaat, natuurlijk ook op een zodanige manier dat je deze weer makkelijk uit je database kunt halen. Deze geserialiseerde constructie is overduidelijk allesbehalve handig omdat je allemaal toeren moet uithalen om de gewenste informatie hier weer uit te peuteren. Sterker nog, dit lukt je niet eens.
Daarnaast kan dit (op termijn) voor performanceproblemen zorgen omdat dit moeilijk (of waarschijnlijk in het geheel niet) te optimaliseren valt. Deze oplossing is dus ook niet schaalbaar naarmate je database groeit.
Het lijkt mij vele malen beter om deze informatie op te slaan in ofwel een of andere kolom of in een koppeltabel, waarbij al "berekend" is wat deze "Divisie" zou moeten zijn zodat je dit niet elke query opnieuw hoeft uit te rekenen. Idealiter staan in databases uitkomsten, geen sommen.
Daarnaast nog het volgende: dat "Level " gedoe voegt waarschijnlijk helemaal niets toe. Dus als je dan toch een geserialiseerd geval in je tabel wilt opslaan (wat dus in dit geval absoluut niet aan te raden valt), wat is er dan op tegen om simpelweg "1:2:3:4:5" op te slaan? Dat is namelijk de enige relevante informatie. Op het moment dat er eigenlijk geen goede andere oplossing is en je echt bent aangewezen op zo'n geserialiseerd ding (en dit zou je dan ook moeten kunnen onderbouwen WAAROM je kiest voor deze constructie, in dit geval is dat ook niet evident) dan zou je ook moeten streven naar een zo kort mogelijke constructie.
Ah well.
Gewijzigd op 11/08/2019 23:44:44 door Thomas van den Heuvel
Dirk Huizinga op 11/08/2019 18:19:21:
Klopt... tikfoutje die puntkomma (;) moet inderdaad een dubbbel punt (:) zijn...
beide methodieken werken
beide methodieken werken
Ik zag enkel een dubbele punt in de explode staan. Maar een ; kan ook als daar op gescheiden zou worden.
Gewijzigd op 11/08/2019 22:29:20 door - Ariën -
Thomas van den Heuvel op 11/08/2019 21:32:13:
Alle bovenstaande antwoorden ten spijt maak je hier de kapitale fout door voort te borduren op een verkeerd ontwerp. Ik snap ook niet waarom niemand je hierop wijst, maar jou behulpzaam denkt te zijn door een rechtstreeks antwoord te geven op jouw vraag. Mogelijk ben je zo gefixeerd geraakt op het vinden van een oplossing dat je bent vergeten dat je min of meer in de problemen bent geraakt doordat je in eerste instantie zelf voor deze aanpak had gekozen... Met andere woorden, je hebt jezelf vastgeprogrammeerd.
Elke keer als ik dit soort constructies zie dan begint het bij mij een beetje te jeuken:
Laten we los van wat je hiermee precies wilt doen eerst eens een analyse maken van deze bovenstaande constructie.
Allereerst: is deze echt nodig? Je bent bezig in een database. Een database is een plek waar je op een gestructureerde manier informatie opslaat, natuurlijk ook op een zodanige manier dat je deze weer makkelijk uit je database kunt halen. Deze geserialiseerde constructie is overduidelijk allesbehalve handig omdat je allemaal toeren moet uithalen om de gewenste informatie hier weer uit te peuteren. Sterker nog, dit lukt je niet eens.
Daarnaast kan dit (op termijn) voor performanceproblemen zorgen omdat dit moeilijk (of waarschijnlijk in het geheel niet) te optimaliseren valt. Deze oplossing is dus ook niet schaalbaar naarmate je database groeit.
Het lijkt mij vele malen beter om deze informatie op te slaan in ofwel een of andere kolom of in een koppeltabel, waarbij al "berekend" is wat deze "Divisie" zou moeten zijn zodat je dit niet elke query opnieuw hoeft uit te rekenen. Idealiter staan in databases uitkomsten, geen sommen.
Daarnaast nog het volgende: dat "Level " gedoe voegt waarschijnlijk helemaal niets toe. Dus als je dan toch een geserialiseerd geval in je tabel wilt opslaan (wat dus in dit geval absoluut niet aan te raden valt), wat is er dan op tegen om simpelweg "1:2:3:4:5" op te slaan? Dat is namelijk de enige relevante informatie. Op het moment dat er eigenlijk geen goede andere oplossing is en je echt bent aangewezen op zo'n geserialiseerd ding (en dit zou je dan ook moeten kunnen onderbouwen WAAROM je kiest voor deze constructie, in dit geval is dat ook niet evident) dan zou je ook moeten streven naar een zo kort mogelijke constructie.
Ah well.
Elke keer als ik dit soort constructies zie dan begint het bij mij een beetje te jeuken:
Code (php)
1
Level 1:Level 2:Level 3:Level 4:Level 5
Laten we los van wat je hiermee precies wilt doen eerst eens een analyse maken van deze bovenstaande constructie.
Allereerst: is deze echt nodig? Je bent bezig in een database. Een database is een plek waar je op een gestructureerde manier informatie opslaat, natuurlijk ook op een zodanige manier dat je deze weer makkelijk uit je database kunt halen. Deze geserialiseerde constructie is overduidelijk allesbehalve handig omdat je allemaal toeren moet uithalen om de gewenste informatie hier weer uit te peuteren. Sterker nog, dit lukt je niet eens.
Daarnaast kan dit (op termijn) voor performanceproblemen zorgen omdat dit moeilijk (of waarschijnlijk in het geheel niet) te optimaliseren valt. Deze oplossing is dus ook niet schaalbaar naarmate je database groeit.
Het lijkt mij vele malen beter om deze informatie op te slaan in ofwel een of andere kolom of in een koppeltabel, waarbij al "berekend" is wat deze "Divisie" zou moeten zijn zodat je dit niet elke query opnieuw hoeft uit te rekenen. Idealiter staan in databases uitkomsten, geen sommen.
Daarnaast nog het volgende: dat "Level " gedoe voegt waarschijnlijk helemaal niets toe. Dus als je dan toch een geserialiseerd geval in je tabel wilt opslaan (wat dus in dit geval absoluut niet aan te raden valt), wat is er dan op tegen om simpelweg "1:2:3:4:5" op te slaan? Dat is namelijk de enige relevante informatie. Op het moment dat er eigenlijk geen goede andere oplossing is en je echt bent aangewezen op zo'n geserialiseerd ding (en dit zou je dan ook moeten kunnen onderbouwen WAAROM je kiest voor deze constructie, in dit geval is dat ook niet evident) dan zou je ook moeten streven naar een zo kort mogelijke constructie.
Ah well.
Toevoeging op 15/08/2019 22:03:26:
Hoi Thomas,
Ben het helemaal eens met wat je zegt. Maar wat je/jullie (nog) niet weten is dat de database die ik gebruik niet zelf door mij is samengesteld en ook niet de manier waarop die gevuld wordt. Het is zo dat de tabellen in de database die ik gebruikt wordt gevoed door csv dumpbestanden van SAP identity management systeem. Echter SAP is log en nogal beperkt hiervoor. Vooral op controles en en rapportages. Dit SAP IDM systeem dumpt dus nu wekelijk een aantal csv bestanden. Tot kort werden deze in een Access database ingelezen en hier konden allerlei queries ontworpen worden. Maar de hoeveel data is te groot voor de MS Access. Neem bijv de tabel autorisaties... alleen al die ene tabel bevat meer dan 3 miljoen records. We willen dus van Access af en willen dat in een MySql database gaan maken. Daarmee dien ik rekening te houden met dat bepaalde data op een bepaalde manier wordt gedumpt in een CSV bestand. Bijvooorveeld geserialiseerd. Ik heb hier geen invloed op en zal ook niet anders worden. Het is een gegeven. In dit geval moest ik deel van de serie 1:2:3:4:5 halen. Het ligt in de lijn der bedoeling dat wanneer een werkend constructie is en dat punt komt steeds dichterbij... dat de bestanden wekelijks worden ingelezen. Maar naarmate alles vordert blijven de (voor mij dan) complexere vraagstukken over, zoals het maken van kruistabel mbv de tabellen om overzichten te genereren. Veel heb ik met jullies hulp ook al plat kunnen slaan en oplossing gevonden.. Maar nu het maken van overzichten is een hekel puntje wat plat geslagen moet worden. Zover reikt mijn kennis nog niet en ben ik zoekende naar oplossing. Maar de hoeveelheid informatie en wedervragen zijn overstelpend en maken de onzekerheid die ik heb alleen maar groter. Dit als achterliggend info zodat jullie klein beetje het idee krijgen waar de problematiek waar ik mee zit vandaan komt.
Quote:
Daarmee dien ik rekening te houden met dat bepaalde data op een bepaalde manier wordt gedumpt in een CSV bestand. Bijvooorveeld geserialiseerd. Ik heb hier geen invloed op en zal ook niet anders worden. Het is een gegeven. In dit geval moest ik deel van de serie 1:2:3:4:5 halen.
Maar als je dit vervolgens importeert in een MySQL-database dan kun je dit toch wel uitsplitsen?
Als performance een probleem is en je daarom wegbeweegt van andere systemen dan lijkt het mij zeker zaak om dit soort plooien meteen plat te strijken.
Quote:
3 miljoen records
Dit zou uit database-optiek geen probleem moeten zijn, maar zelfs als je dit efficiënt kunt uitlezen is het de vraag of je dit wel wilt? Dit lijkt mij veel te veel informatie om als gebruiker in 1x te kunnen behapstukken en hoe zou de interface voor dit soort informatie er dan uit moeten zien?
Ik zou in eerste instantie echt de nadruk leggen op het database-ontwerp, met mogelijk al in het achterhoofd hoe je deze informatie uit wilt gaan lezen/wilt gaan gebruiken. Als het fundament goed is, is de rest verder relatief eenvoudig. Als het fundament echter niet zo sterk is (nog steeds geserialiseerde meuk in je database terwijl dit niet nodig is) dan maak je borst maar nat voor allerlei problematiek als gevolg van een gebrekkig ontwerp. Dit kan nooit iets efficients opleveren. Rapportages zouden (haast) een kwestie van gegevens uitdraaien moeten zijn.
op dit forum, alle goede bedoelingen daargelaten hoor, durf je bijna geen post meer te plaatsen omdat je, gevoelsmatig, alles wat je probeert als fout wordt behandeld... Dit kan misschien wel zijn dat neem ik ook aan. Maar de ontvanger heeft het PHP handboek niet geschreven. Daarbij zoveel koppen, zoveel meningen. Nogmaals niet negatief bedoeld maar dit helpt ook niet verder.
Ik denk dat ik het hierbij maar moet gaan laten. Ik kom dwaal gevoelsmatig verder en verder van mijn vraag weg en krijg het gevoeld dat ik me haast moet verdedigen. Ik haal mede dankzij de hulp van velen al allerlei overzichten uit de database en daar kom ik ook wel heel eind mee.. De kruistabel laat ik maar zitten .
Iedereen die op welke manier ook een bijdrage aan mijn vraagstukken heeft geleverd wil ik bij deze nogmaals bedanken voor hun tomeloze inzet en geduld. Het is goed zo. dank jullie wel.
Daarnaast moet de discussie ook ruimte kunnen bieden voor goede beargumentatie, en dat er geen dingen worden doorgedrukt. Als een oplossing écht niet anders kan en dat er een mindere goede oplossing worden gekozen, dan moet dat dan maar.
- Ariën - op 16/08/2019 09:54:07:
Daarnaast moet de discussie ook ruimte kunnen bieden voor goede beargumentatie, en dat er geen dingen worden doorgedrukt.
Actually, er wordt hier simpelweg te vaak rechtstreeks antwoord gegeven op een vraag, zonder een analyse te maken van wat er nou precies gebeurt. Als iemand geserialiseerde zut in zijn database stopt dan moet je je serieus afvragen wat daarvan het nut is, of dat echt nodig is, en of dit niet op een andere manier kan. Het enige wat je anders aan het doen bent is iemand helpen om iets op de verkeerde manier op te lossen. Dit is letterlijk iemand blij maken met een dode mus.
Dan over het "dingen doordrukken". Je moet hierbij onderscheid maken tussen #1 de gekozen aanpak en de #2 bijbehorende implementatie. #2 zou logisch voort moeten vloeien uit #1 en daarbij maakt het niet eens zoveel uit hoe #2 er *precies* uitziet, zolang het de principes van #1 maar volgt. Maar #1 moet staan als een huis en gedragen worden door valide argumenten. Daar moet geen speld tussen te krijgen zijn.
- Ariën - op 16/08/2019 09:54:07:
Als een oplossing écht niet anders kan en dat er een mindere goede oplossing worden gekozen, dan moet dat dan maar.
En ook dat moet onderbouwd zijn anders heb je gewoon geen excuus om het je zelf er maar makkelijk vanaf te maken. Vaak is een bijkomend nadeel van zo'n aanpak ook dat je in wezen werk voor je uitschuift en dat is een schuld die je vroeg of laat toch zult moeten inlossen... vaak op een moment dat je al weer met een andere klus bezig bent. Maar als je enkel met de korte termijn bezig bent dan ga je waarschijnlijk voorbij aan het feit dat je op de lange termijn netto meer tijd kwijt bent met zo'n aanpak. Er is voor beide aanpakken iets te zeggen maar ik weet wel welke fijner werkt.
Het systeem van de topicstarter zal vast in eerste instantie groot, complex en ontoegankelijk ogen, maar als het de bedoeling is dat dit wordt omgezet in een (echte) relationele database dan lijkt het mij dat je echt tijd investeert in een verkenning zodat je kunt doorgronden wat alles inhoudt en hoe je dit vervolgens omzet in iets efficiënts. Dat was volgens mij het hele doel van deze exercitie. Hier kun je niet op voorhand allemaal bezuinigingen doorvoeren en dan maar hopen dat alles op zijn pootjes terechtkomt. Het helpt hierbij natuurlijk ook als je volgens een (stappen)plan te werk gaat. En als dan een stap meer tijd kost kun je overleggen wat je dan doet en eventueel dingen snoeien. Maar ook dit zijn allemaal beslissingen die een onderbouwing (zouden moeten) hebben.
Je kunt dit soort dingen niet even tussendoor freewheelen...
Wat ik wel ervaar dat wat je ook post.. (meestal al een hulpvraag) dan komen er allemaal goed bedoelde adviezen die een beginnneling alleen maar nog onzekerder maakt. Ik weet niet hoe jullie de kennis heb vergaard maar ik moet het hier op doen en dan bevordert al die welgemeende opvattingen en methodieken niet. Simpel door het feit dat ik een stadia bevind waar je me alles wijs kan maken. Nogmaals ik kan niet met iemand klankborden van hoe en/of wat. moet het maar zien te rooien. Nu gebeurt precies wat ik in mijn vorige antwoord al schreef... ik dwaal verder en verder af van de vraag. want we borduren alleen voort op het laatste antwoord die heeft gegeven. Zoals ik al eerder zei. Ik zit vast aan een aantal dumpbestanden die wekelijks iedere keer worden ververst. Inhoudelijk op de bestanden kan ik geen invloed uitoefenen en ik zit nu met aantal geserialiseerde velden.. Dit kunnen we natuurlijk zut vinden.. en dat is misschien ook wel zo. Maar het wel een gegeven. Dat kan in niet veranderen. Ook dit veld wordt wekelijks gedumpt... Ruimte voor discussie moet mogelijk zijn maar daarbij zou het fijn zijn dat er rekening wordt gehouden dat niet iedereen op hetzelfde niveau werkt, denkt.
Nogmaals ik wil niemand tegen het zere been schoppen. Maar het nivo verschil is te hoog daardoor wordt er niet gelijkwaardig gecommuniceerd. Nogmaals iedereen bedankt die me met topics verder heeft geholpen. Deze laat ik rusten.
Quote:
Ik zit vast aan een aantal dumpbestanden die wekelijks iedere keer worden ververst. Inhoudelijk op de bestanden kan ik geen invloed uitoefenen en ik zit nu met aantal geserialiseerde velden.. Dit kunnen we natuurlijk zut vinden.. en dat is misschien ook wel zo. Maar het wel een gegeven. Dat kan in niet veranderen. Ook dit veld wordt wekelijks gedumpt...
Dat heb ik ook nooit bestreden, daar zul je het inderdaad mee moeten doen. Het enige wat ik voorstel is dat je dit:
Code (php)
1
Level 1:Level 2:Level 3:Level 4:Level 5
op voorhand omzet naar iets werkbaars zodat je je niet in allerlei onmogelijke bochten hoeft te wringen om er mee te kunnen werken. Dit zou je dus moeten doen bij de import. Daar zou wat meer kennis over wat dit betekent toegepast moeten worden zodat je meteen de beschikking hebt over deze "Divisie" die je blijkbaar nodig hebt/belangrijk is.
Als je alles/het grootste deel 1:1 importeert dan blijft het behelpen. De juiste plek om het bovenstaande probleem op te lossen is dus bij de import, niet in de uiteindelijke query waarbij er grote moeite gedaan moet worden om de juiste informatie er uit te peuteren. Als dat aan de orde is dan is er gewoon iets mis met de opzet want het zou makkelijk moeten zijn om de gewenste informatie op te vragen in een database. Dit houdt dus ook in dat informatie in eerste instantie op een toegankelijke manier moet worden opgeslagen. "Level 1:Level 2:Level 3:Level 4:Level 5" is allesbehalve toegankelijk want dit is (onnodig) geëncodeerde data.
EDIT: en als het allemaal te moeilijk is dan schakel hulp in van iemand die inhoudelijk mee kan kijken en/of verstand van het systeem heeft. Een forum kan moeilijk (op afstand) een compleet automatiseringsvraagstuk oplossen in een enkele thread...
Mijn advies is wel dat je een knoop doorhakt. Doe het WEL of doe het NIET, maar doe het niet HALF.
Gewijzigd op 16/08/2019 14:01:03 door Thomas van den Heuvel