Index naam

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Backend Developer PHP Laravel SaaS

Dit ga je doen Het ontwikkelen van nieuwe features die bijdragen aan de groei van de klanten van de organisatie; Je denkt mee over nieuwe innovaties, features en verbeteringen in de applicatiearchitectuur; Je draagt bij aan de continue ontwikkeling van jouw team doordat je elke dag streeft naar het verbeteren van jouw eigen prestaties; Je neemt actief deel aan Scrum meetings en de Backend Guild. Hier ga je werken Voor een snel groeiend bedrijf, in de regio Nieuw Vennep, zijn wij opzoek naar een ervaren Backend Developer. De organisatie is actief in de e-commercebranche en ontzorgt haar klanten middels een

Bekijk vacature »

API Developer Red Hat Fuse

Dit ga je doen Als API Developer zal je verantwoordelijk zijn voor het: het maken van API's en het correct laten draaien van de API's op het platform. Hierdoor kom je in aanraking met Red Hat Fuse, Springt Boot, 3Scale, Red Hat SSO, Openshift en Azure DevOps; zorgen voor de kwaliteit van de ontwikkeling, integratie en prestaties van de API's; zorgen voor een stabiel integratieplatform. Hier ga je werken Deze organisatie is een toonaangevende speler in de vastgoedbranche en telt momenteel ruim 500 medewerkers. Met meer dan 150 applicaties staat er een complex applicatielandschap dat hoofdzakelijk op OpenShift, Azure en

Bekijk vacature »

Medior/Senior Python developer

Functie Jij als Senior Python developer hebt al ruime ervaring opgedaan. Bedrijven komen bij de organisatie om technische vraagstukken op te lossen. Jij als specialist bent dus de representatie van deze kwaliteit. Je zult de keuze krijgen tussen lange of korte projecten waarin je komt te werken in multidisciplinaire teams. Projecten die je gaat uitvoeren zijn zeer uitlopend. Zodoende kun je aan de ene kant kiezen voor een greenfield project en stroom je bij een ander project midden in een migratietraject in. Voor de ene klant ontwikkel je ene nieuwe portal en voor het andere project duik je veel meer

Bekijk vacature »

Fullstack Software Developer

Functieomschrijving Voor een ambitieuze werkgever in regio Roosendaal zijn wij op zoek naar een Full Stack C#.NET Developer. Als software programmeur ben je verantwoordelijk voor het bouwen van webapplicaties, apps en dashboards voor de eigen IOT-oplossingen. Je werkt samen met andere developers en engineers om de sensoren in machines uit te lezen en deze data om te zetten in management informatie voor jullie klanten. Taken en verantwoordelijkheden: Verder ontwikkelen en onderhouden van webapplicaties, dashboards en apps voor de eigen IOT-oplossingen; Testen en goedkeuren van de software; Je gaat aan de slag met de volgende technologieën en frameworks: C#, JS frameworks,

Bekijk vacature »

SAP Integratie Ontwikkelaar

Ben jij ambitieus in de verdere ontwikkeling van SAP binnen HANOS, en heb je kennis van SAP PI, CPI (SAP integration suite) en of andere middleware tooling? Dan ben jij mogelijk onze nieuwe SAP Integratie (middleware) Ontwikkelaar! Lees snel verder en solliciteer! Wat ga je doen? Als SAP Financieel Consultant ben je, als deel van een gedreven team van interne SAP consultants, de schakel tussen de gebruikersorganisatie en ICT. Je draagt proactief bij aan een optimale aansluiting van de SAP-functionaliteit (een applicatielandschap met o.a. Suite on HANA, Fiori, Hybris, C4C en BO), op de bedrijfsprocessen. Verder ondersteun je de HANOS

Bekijk vacature »

Software Programmeur PHP - JAVA

Functie Wil jij bij een platte en informele organisatie werken? Lees dan snel verder! Voor een opdrachtgever in omgeving Boskoop dat zich gespecialiseerd heeft in het realiseren van veilige netwerkverbindingen zijn wij op zoek naar een leuke software developer ter versterking van het huidige team. Hoe kan jouw dag er straks uitzien? Je gaat technische klussen uitvoeren op locatie bij klanten.Je onderhoudt contact met de projectleider om er zeker van te zijn dat een projecten goed verlopen. Je gaat klanten ondersteunen op het gebied van geleverde software en webapplicaties. Je gaat software en webapplicaties ontwikkelen met behulp van de talen

Bekijk vacature »

Junior .NET developer

Functie Wij hebben drie scrumteams. Het eerste team focust zich op het stukje hardware wat wij in huis doen. Zij maken als team o.a. gebruik van C++. De andere twee scrumteams zijn allebei bezig met data verwerking en maken hierbij in de backend gebruik van C# .NET / .NET Core. Het verschil tussen deze teams is dat één team de data verwerking doet voor de mobiele applicatie. Zij werken hierbij dus ook met Xamarin. Het andere team focust zich op de webapplicaties en maakt hierbij ook gebruik van ASP.NET MVC. Op basis van jouw ambities en kwaliteiten kijken wij samen

Bekijk vacature »

Junior .NET developer

Functie Als junior .NET ontwikkelaar start jij in een ontwikkelteam met 7 .NET developers. In ons team werken er drie senior .NET developer, twee medior .NET developers en twee junior .NET developers. Er is dan ook genoeg senioriteit in ons team om jou te kunnen bieden wat jij nodig hebt! Wij werken in scrum en hebben drie wekelijkste sprints. Daarnaast doen wij minimaal vier keer per jaar een release. Ons platform is ontzettend complex en groot. Het is dan ook in het begin belangrijk dat jij de processen gaat begrijpen. Jij krijgt dan ook een cursus om beter te begrijpen

Bekijk vacature »

Medior Java developer (fullstack)

Wat je gaat doen: Of beter nog, wat wil jij doen? Binnen DPA GEOS zijn we dan ook op zoek naar enthousiaste Java developers om ons development team te versterken. Als Java developer werk je in Agile/Scrum teams bij onze klanten en daarbij kun je eventueel ook andere ontwikkelaars begeleiden in het softwareontwikkelproces. Verder draag je positief bij aan de teamgeest binnen een projectteam en je kijkt verder dan je eigen rol. Je gaat software maken voor verschillende opdrachtgevers in jouw regio. Je bent een professional die het IT-vak serieus neemt en kwaliteit levert. Je leert snel vanwege je diepgaande

Bekijk vacature »

Traineeship Full Stack .NET Developer

Dit ga je doen Start op 7 augustus 2023 bij de Experis Academy en ontwikkel jezelf tot een gewilde Full Stack .NET Developer. Maar hoe ziet het traineeship eruit en wat kun je verwachten? Periode 1 De eerste 3 maanden volg je fulltime, vanuit huis, een op maat gemaakte training in teamverband. Je leert belangrijke theorie en krijgt kennis van de benodigde vaardigheden en competenties die nodig zijn om de IT-arbeidsmarkt te betreden. Zowel zelfstandig als in teamverband voer je praktijkopdrachten op het gebied van front- en backend development uit. Wat er per week op het programma staat kun je

Bekijk vacature »

PHP developer (Symfony, Doctrine)

Functie Als PHP developer wordt er een hoge mate van zelfstandigheid verwacht, maar ook dat je goed opereert in een team waar kennis wordt gedeeld en dingen als codereviews erg veel voorkomen. Kwaliteit staat voorop, mede hierom werken ze bijvoorbeeld zonder echte deadlines in hun sprints. De SaaS-applicatie wordt volledig ontwikkeld in PHP en Symfony. De module bestaat uit een stuk informatie verrijking en intelligentie wat resulteert in een medische check. De logica wordt daarom in de code geïntrigeerd. Je bent onder andere bezig met complexe databases waar meer dan 80.000 medicijnen op verschillende niveaus in staan, die maandelijks worden

Bekijk vacature »

Mendix Developer

Voor Troostwijk Groep zoeken wij een: Mendix Developer Wij zoeken Je bent een getalenteerde en ervaren Mendix Developer en het is tijd om je horizon te verbreden. Je wilt minder coderen en meer modelleren, minder bezig zijn met allerlei technische details en randvoorwaarden en meer met functionaliteit. Daarnaast ben je trots op de innovatieve en gebruiksvriendelijke applicaties die je in de loop van de jaren hebt gebouwd. Werk je graag in een enthousiast team, wil je veel vrijheid en kun je tegelijkertijd goed met deadlines omgaan, dan ben jij absoluut degene die wij zoeken! Wat je nodig hebt is ruime

Bekijk vacature »

Senior .NET Developer I goed salaris en deels thui

Bedrijfsomschrijving Mijn opdrachtgever is al ruim 20 jaar een gevestigde naam in de wereld van software ontwikkeling, met drie kantoren in de Randstad, waaronder Alphen aan den Rijn. Zij richten zich op het bouwen van IT-oplossingen die ervoor zorgen dat de productiviteit van klanten te allen tijden optimaal is. Hiervoor neemt jouw nieuwe werkgever het volledige ontwikkelproces tot haar rekening; van het eerste gesprek om de klantwensen in kaart te brengen, tot aan het uiteindelijke onderhoud van de opgeleverde oplossing. In totaal werken er inmiddels bijna 200 gemotiveerde IT-ers binnen deze organisatie. De gemiddelde leeftijd ligt rond de 35. Het

Bekijk vacature »

C++ Ontwikkelaar

Functieomschrijving Ben jij als software ontwikkelaar toe aan een nieuwe uitdaging? Dan zoeken wij jou! Voor het maken van de procesbesturingssoftware gebruiken onze projectteams een in C++ en C# geschreven tool. Dit is een gedistribueerd object framework wat alle kernfuncties biedt voor een procesautomatisering. Verder zullen jouw werkzaamheden o.a. bestaan uit: Ontwerpen, programmeren en testen van product aanpassingen; Analyseren van vragen en wensen van gebruikers en deze vertalen naar een functioneel ontwerp; Inzichtelijk maken van voortgang omtrent softwarewerkzaamheden, o.a. door middel van SCRUM; Continu toetsen van het effect van nieuwe releases op andere tools en processen; Implementeren van nieuwe product

Bekijk vacature »

Full Stack C#.NET developer

Functieomschrijving Wij zijn op zoek naar een gepassioneerde Full Stack C#.NET Software Developer. Als Software Developer ben je verantwoordelijk voor het ontwikkelen van webapplicaties, apps en dashboards voor de eigen IOT-oplossingen. Je werkt samen met andere ontwikkelaars en engineers om de sensoren in machines uit te lezen en deze data om te zetten in management informatie voor jullie klanten. Taken en verantwoordelijkheden: Ontwikkelen en onderhouden van webapplicaties, apps en dashboards voor de eigen IOT-oplossingen. Testen en valideren van de ontwikkelde software. Actief deelnemen aan code reviews en bijdragen aan het verbeteren van de kwaliteit van de software. Je gaat aan

Bekijk vacature »
Jordy nvt

Jordy nvt

08/08/2011 14:42:29
Quote Anchor link
Op het moment ben ik indexes aan het toevoegen met de volgende query:

$query= "CREATE INDEX index_naam ON tabel (veld)";

Nu vraag ik mij alleen af wat de index_naam precies inhoudt. Ik kan er nergens wat over vinden, maar kan ik gewoon dezelfde naam als het veld gebruiken? Of moet het over de gehele database een unieke naam zijn? Wat is het nut er precies van?

Bedankt!
 
PHP hulp

PHP hulp

21/11/2024 21:06:35
 
Benny Lava

Benny Lava

08/08/2011 14:56:31
Quote Anchor link
Hier zijn links waar je meer info uit kunt halen:
http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html
http://dev.mysql.com/doc/refman/5.0/en/create-index.html

En ik neem aan dat je niet de zelfde kolom naam kunt gebruiken als index naam; Want dan zal die waarschijnlijk niet weten of je de index of de kolom bedoeld. Maarja, kom je achter door te proberen neem ik aan? ;)
 
Jordy nvt

Jordy nvt

08/08/2011 14:58:35
Quote Anchor link
Ja, dat kan wel en ik heb al die dingen al doorgelezen. Maar ik kom niet echt achter het nu en de voor/nadelen en voorwaarden van een index_naam.
 
Benny Lava

Benny Lava

08/08/2011 15:02:20
Quote Anchor link
1keydata.com 08/08/2011:
There is no strict rule on how to name an index. The generally accepted method is to place a prefix, such as "IDX_", before an index name to avoid confusion with other database objects. It is also a good idea to provide information on which table and column(s) the index is used on.
 
Jordy nvt

Jordy nvt

08/08/2011 16:33:29
Quote Anchor link
Mijn fout, bedankt voor het plaatsen van de tekst. Sorry!

Toevoeging op 08/08/2011 16:41:49:

Maar wat wordt er eigenlijk precies mee gedaan? Is het gewoon zinloos of moet je er goed over nadenken en later gebruiken ofzo?
 
Benny Lava

Benny Lava

08/08/2011 17:02:46
Quote Anchor link
Ik heb zelf nooit echt indexing nodig gehad, maar even de voor/nadelen. Te beginnen met de nadelen omdat die iets makkelijker zijn op te noemen.

Nadelen
- Extra onderhoud om de indexen actueel te houden mocht de database veranderen;
- Indexen is niet bedoeld om queries te optimaliseren, het maakt het juist minder overzichtelijker omdat extra documentatie nodig is;
- Het is eigenlijk alleen maar nuttig met queries waarbij veel WHERE gebruikt wordt;

Voordelen
- Bij een grote database hoeft MySQL minder te zoeken naar de juiste kolom;
- Het kan handig zijn voor een DB administrator (maar die zullen dit waarschijnlijk overslaan);

Nouja, da's een beetje de voor/nadelen die ik zover zie over het gebruik van indexen. Wat het op neer komt is dat het afhankelijk kan zijn wat je precies wilt doen met je database. Maar het is zeker geen manier om de queries te optimaliseren mocht je dat van plan zijn. En eigenlijk kan ik je aanraden hier dan ook niet aan te beginnen of het moet een webapplicatie zijn die zoooooo groot is en dat dit ook echt verschil kan uitmaken, maar dan heb je waarschijnlijk een DB administrator voor die dit kan uitzoeken. ;)
 
Jordy nvt

Jordy nvt

08/08/2011 17:05:49
Quote Anchor link
Ok, maar je hebt het toch ook nodig voor foreign keys? Want daar ben ik nu mee bezig. Dat bespaart een hoop werk dat als iets wordt verwijderd, de bijbehorende data in andere tabellen ook wordt verwijderd.
 
Benny Lava

Benny Lava

08/08/2011 17:13:57
Quote Anchor link
Daarvoor schrijven ze voor dat je de ALTER TABLE gebruikt en niet de CREATE INDEX.

Hier een tut. erover:
Klik hiero
Gewijzigd op 08/08/2011 17:14:23 door Benny Lava
 
Jordy nvt

Jordy nvt

08/08/2011 18:59:21
Quote Anchor link
Ok bedankt. Maar wat is daar het verschil mee dan? Je geeft ze toch bij beide methoden een index?
 
Kees Schepers

kees Schepers

08/08/2011 19:36:34
Quote Anchor link
Het verschil is bij mijn weten niets. Create index is puur syntax wijs anders.
 
Jordy nvt

Jordy nvt

08/08/2011 19:40:01
Quote Anchor link
Ok, en als laatste. Wat kun je beter doen. Telkens een nieuwe index creëren op een kolom en deze een leuke naam geven of één naam geven per tabel en daaronder meerdere tabellen stoppen. Wat is precies het verschil of maakt dat ook niet uit?
 
Kees Schepers

kees Schepers

08/08/2011 19:43:33
Quote Anchor link
Benny Lava op 08/08/2011 17:02:46:
Ik heb zelf nooit echt indexing nodig gehad, maar even de voor/nadelen. Te beginnen met de nadelen omdat die iets makkelijker zijn op te noemen.

Nadelen
- Extra onderhoud om de indexen actueel te houden mocht de database veranderen;
- Indexen is niet bedoeld om queries te optimaliseren, het maakt het juist minder overzichtelijker omdat extra documentatie nodig is;
- Het is eigenlijk alleen maar nuttig met queries waarbij veel WHERE gebruikt wordt;

Voordelen
- Bij een grote database hoeft MySQL minder te zoeken naar de juiste kolom;
- Het kan handig zijn voor een DB administrator (maar die zullen dit waarschijnlijk overslaan);

Nouja, da's een beetje de voor/nadelen die ik zover zie over het gebruik van indexen. Wat het op neer komt is dat het afhankelijk kan zijn wat je precies wilt doen met je database. Maar het is zeker geen manier om de queries te optimaliseren mocht je dat van plan zijn. En eigenlijk kan ik je aanraden hier dan ook niet aan te beginnen of het moet een webapplicatie zijn die zoooooo groot is en dat dit ook echt verschil kan uitmaken, maar dan heb je waarschijnlijk een DB administrator voor die dit kan uitzoeken. ;)


WTF?! Volgens mij heb jij niet met grotere en genormaliseerde databases gewerkt. Bij tabellen van meer dan 1000 records beginnen indices enorme performance winsten te geven. Ook je nadelen vind ik niet helemaal kloppen:

Extra inhoudt; Dit had je beter kunnen omschrijven als: "Meer (schijf)ruimte die gebruikt wordt voor het bijhouden van de index. Echter is dat meestal niet het ergste maar vooral hoe meer indexen je hebt des te trager je inserts en updates worden omdat stukken van je index dan aangepast moeten worden.

Een index is JUIST bedoeld om queries te optimaliseren. Een index afhankelijk van het type kan enorme performance winsten opleveren bij het gebruik op WHERE condities maar ook als je tabellen joint gaat het matchen van velden sneller.

Het is nuttig bij queries waar elke vorm van vergelijking optreedt. Echter dient men af te wegen om wat voor performance winst het gaat en wat een eventuele extra index aan performance kost voor mutaties.

Benny Lava op 08/08/2011 14:56:31:
Hier zijn links waar je meer info uit kunt halen:
http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html
http://dev.mysql.com/doc/refman/5.0/en/create-index.html

En ik neem aan dat je niet de zelfde kolom naam kunt gebruiken als index naam; Want dan zal die waarschijnlijk niet weten of je de index of de kolom bedoeld. Maarja, kom je achter door te proberen neem ik aan? ;)


Kan gewoon hoor?

Jordy nvt op 08/08/2011 19:40:01:
Ok, en als laatste. Wat kun je beter doen. Telkens een nieuwe index creëren op een kolom en deze een leuke naam geven of één naam geven per tabel en daaronder meerdere tabellen stoppen. Wat is precies het verschil of maakt dat ook niet uit?


Je zinsloop klopt niet helemaal maar ik veronderstel dat je vraag is of een index wilt met een kolom of een index met meerdere kolommen. Dit hangt ervan af:

Stel je hebt de volgende query:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
SELECT * FROM users WHERE username LIKE "ke%" AND insertdate > NOW() - INTERVAL 2 MONTH


In bovenstaand geval doe je een vergelijking op 2 velden. Specifiek voor deze query loont het zich om een index te maken op 2 velden als volgt dus:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
ADD INDEX somename ON users (username, insertdate)


Echter in het volgende geval:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
SELECT * FROM users WHERE username LIKE "ke%"


Loont het zich meer de moeite om:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
ADD INDEX somename ON users (username)


Te doen.

Om te bepalen wat je het beste kunt doen is te kijken naar wat voor queries je afvuurt op de betreffende tabel. Bij deze queries analyseer je welke velden het meest gebruikt worden bij het maken van matches en wat de kardinaliteit is, hoe hoger deze is des te meer ruimte de index in beslag zijn nemen en de insert en updates trager zullen worden. Tevens hangt het er ook vanaf hoe belangrijk de performance van je insert's en updates is.

Er is dus niet echt zo te zeggen wat je het beste kunt doen. Dit kun je dus het beste bepalen door goed te kijken wat voor queries er gebruikt worden en wat de grote is van tabellen. Bij foreign keys moeten er altijd indexen gelegd worden. Daarom zijn MySQL databases met hogere integriteit altijd wat zwaarder.


In dit artikel ga ik ook nog wat verder in op performance en het gebruik van indexes.
Gewijzigd op 08/08/2011 19:51:43 door kees Schepers
 
Jordy nvt

Jordy nvt

08/08/2011 20:01:54
Quote Anchor link
Bedankt voor je uitgebreide reactie. Je antwoord is niet precies wat ik met mijn vraag bedoelde maar dat maakt niet uit:-) Heb even een afbeelding gemaakt. Hopelijk maakt dat het wat duidelijker. http://imageshack.us/photo/my-images/11/indexvb.png/
 
Kees Schepers

kees Schepers

08/08/2011 20:09:10
Quote Anchor link
Uhm, mijn antwoord slaat wel op je vraag. Tenminste als je naar de afbeelding kijkt die je gegeven hebt. Je hebt hier namelijk 2 situaties bij de eerste gebruik je voor elk veld een aparte index en bij de tweede een index voor meerdere velden. Dat heeft veel te maken met mijn bovenstaande uitleg.
 
Jordy nvt

Jordy nvt

08/08/2011 20:15:12
Quote Anchor link
Ok, maar dan is het toch gunstiger om het allemaal apart te doen? Stel dat ik af en toe zoek op WHERE veld1=$var1 AND veld2=$var2 maar dat ik ook af en toe apart zoek per veld. Moet ik dan afwegen wat gunstiger zou zijn, of volstaat één van de twee mogelijkheden die ik in de screenshot aangaf dan ook?
 
Kees Schepers

kees Schepers

09/08/2011 17:57:15
Quote Anchor link
Nee dan zul je dat af moeten wegen. Als jij 2 losse indexen maakt en je voert een query uit zoals: WHERE veld1=$var1 AND veld2=$var2 dan wordt deze index niet gebruikt! Je kunt ook nog 2 losse indexen en 1 index met 2 velden erin maken. Maargoed voor alles geld dat je goed moet nagaan hoe noodzakelijk het is en wat de eisen en resultaten zijn van je applicatie.

In sommige gevallen is het noodzakelijk of 'best approach' om je een klein stukje van je database te denormaliseren voor performance winst. Ik heb weleens zo'n situatie gehad waarbij een order een many-to-many relatie had, dus je had de tabellen order, order_to_statustype en statustype. Om de laatste status op te vragen moest ik dus elke keer een subquery doen met een MAX op de insertdate.

Dit ging goed tot een paar honderd duizend records maar door de indexen groeide de tabel erg hard en werd het steeds langzamer. De beste oplossing was op een gegeven moment op de tabel order_to_statustype een trigger (after) toe te voegen op insert en delete die na het toevoegen van een status de laatste statusid koppelde aan de order tabel in een veld order.orderlaststatusid. Hierdoor kon ik rechtstreeks een join schrijven zonder subqueries.

Ik hoop dat je het een beetje snapt en dat het voor je wat toevoegt in het kader van performance overwegingen.
 
Bartje Jansen

Bartje Jansen

09/08/2011 21:28:25
Quote Anchor link
Na lang meegelezen te hebben op PHPhulp, moest ik toch even reageren op de volgende reactie:
Benny Lava op 08/08/2011 17:02:46:
Ik heb zelf nooit echt indexing nodig gehad, maar even de voor/nadelen. Te beginnen met de nadelen omdat die iets makkelijker zijn op te noemen.

Nog nooit? Heb je nog nooit een primary key of een unique constraint in een database gebruikt? Dan heb je eigenlijk nog nooit iets met een database gedaan en hebben jouw opmerkingen vrij weinig waarde.

Het feit dat je niet weet dat een primary key en unique constraint in MySQL een index aanmaken, zegt eigenlijk ook al dat je er niets vanaf weet.


Quote:
Nadelen
- Extra onderhoud om de indexen actueel te houden mocht de database veranderen;

Over welk onderhoud heb je het dan? Die ene microseconde om een index bij te werken? Lijkt mij niet zo spannend.
Quote:
- Indexen is niet bedoeld om queries te optimaliseren,

Hoe zeg je? Een index zal een query inderdaad niet optimaliseren, het uitvoeren van een query kan dankzij een index wel enorm worden geoptimaliseerd. Een query die geen index kan gebruiken, zal altijd een sequential scan uitvoeren en dus altijd de hele tabel moeten uitlezen. Met grote tabel kost dat dus een eeuwigheid. Een indexscan kan met kleine hoeveelheden data uit een hele grote tabel nog steeds binnen enkele microseconden plaatsvinden.

Quote:
het maakt het juist minder overzichtelijker omdat extra documentatie nodig is;

Je hebt hier echt geen idee waar je het over hebt, je kraamt hier onzin uit. Een query wordt nooit onoverzichtelijker omdat er toevallig indexen in een database aanwezig zijn. En wat documentatie er mee te maken heeft, geen idee.

Quote:
- Het is eigenlijk alleen maar nuttig met queries waarbij veel WHERE gebruikt wordt;

En wat dacht je van sorteren? Of een JOIN? Of een GROUP BY? Een query waarbij je alle gegevens in een tabel opvraagt, komt vrijwel nooit voor en dus heb je er vrijwel nooit baat bij om geen indexen te gebruiken. Waar haal je deze onzin toch vandaan?

Quote:
Voordelen
- Bij een grote database hoeft MySQL minder te zoeken naar de juiste kolom;

Nog mee onzin... Waarom zou de database naar een kolom moeten zoeken? Die geef jij al op in jouw query, heeft niets met een index te maken. Een index gebruik je om snel records te vinden.

Quote:
- Het kan handig zijn voor een DB administrator (maar die zullen dit waarschijnlijk overslaan);

Sorry, maar ook hier begrijp ik helemaal niets van. Waarom zou een index handig zijn voor een DBA? Een index is er voor de database, voor de betere performance.

Quote:
Nouja, da's een beetje de voor/nadelen die ik zover zie over het gebruik van indexen. Wat het op neer komt is dat het afhankelijk kan zijn wat je precies wilt doen met je database. Maar het is zeker geen manier om de queries te optimaliseren mocht je dat van plan zijn. En eigenlijk kan ik je aanraden hier dan ook niet aan te beginnen of het moet een webapplicatie zijn die zoooooo groot is en dat dit ook echt verschil kan uitmaken, maar dan heb je waarschijnlijk een DB administrator voor die dit kan uitzoeken. ;)

Je hebt geen enkel idee wat een DBMS is en wat een DBMS zou moeten doen en hoe deze intern werkt. Je hebt echt geen flauw benul. Niemand is perfect, maar accepteer ook van jezelf dat je niet alles weet en ook niet over alles mee hoeft te praten.

Tip: Verwijder bovenstaande onzin, dan sta je iets minder voor gek.

Ps. Sorry als het wat bot is, het is niet persoonlijk bedoelt en ik hoop dat je er nog iets van leert.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.