Index naam

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

.NET developer

Functie Jij begint als .NET ontwikkelaar in een team met 10 andere Software Engineers. De werkzaamheden zijn afwisselend, zo kan het dat jij bezig bent met volledig nieuwe features of het door ontwikkelen van bestaande sites of shops. Wij ontwikkelen web applicaties, maar ook mobiele applicaties. Daarnaast bijt jij je soms ook van in externe koppelingen met systemen zoals een ERP. Als team is er een duidelijke focus m.b.t. het waarborgen van de performance en snelheid van webshops. Ook zijn wij expert op het gebied van configuratoren. Kortom enorm veel afwisselende werkzaamheden! Ook jouw werkplek kan afwisselend zijn. Soms heb

Bekijk vacature »

Software Programmeur

Functie omschrijving Ben jij op zoek naar een organisatie waar je samen met een team werkt aan iets moois en waar je naast hard werken ook hard kunt lachen? Dan ben je hier aan het juiste adres! Voor een informeel IT-bedrijf in omgeving Wassenaar zijn wij op zoek naar versterking. Ben jij op zoek naar een nieuwe uitdaging als Software Programmeur lees dan snel verder! Werkzaamheden Programmeur Je bent bezig met het ontwikkelen van software en webapplicaties. Je kunt technische klussen uitvoeren op locatie. Je onderhoudt contact met de projectleider om er zeker van te zijn dat een project goed

Bekijk vacature »

Senior .NET developer

Functie Als Senior .NET ontwikkelaar ga jij aan de slag in ons Research & development team. Ons team bestaat uit 17 collega’s! Wij zijn momenteel druk bezig met het opzetten van een geheel nieuwe architectuur voor een nieuw product. Hierbij maken wij o.a. gebruik van VS2022 en .NET 6.0. Jouw functie is dan ook voornamelijk backend georiënteerd bij ons. Aangezien wij meetapparatuur ontwikkelen voor de chemische industrie is het ook erg belangrijk om kwalitatief hoogwaardige software te ontwikkelen voor de besturing hiervan. Verder ben jij verantwoordelijk voor het designen, implementeren en testen van nieuwe features. Ook zorg jij voor toekomstbestendige

Bekijk vacature »

Junior Front end developer

Functie Jij als developer gaat ons helpen onze producten verder te ontwikkelen en in te zetten in de markt. Op dit moment bestaat ons SaaS product uit 3 componenten die zowel los als in een pakket gekocht kunnen worden. Het gaat hier om een online kaartapplicatie, een workflow tool en een monitoring tool. Momenteel zijn wij 3 jaar geleden gestart met de ontwikkeling. De tech-stack waarmee we werken is voornamelijk Javascript, Vue.js en Python. Daarnaast gebruiken wij FaundaDB als database en werken we veel met GIS applicaties. De uitdaging die we momenteel hebben is dat we momenteel een intern team

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 »

Back-end PHP Software Developer - Juniorfunctie

Functieomschrijving Wij zijn op zoek naar een PHP Software Developer om ons team te versterken en mee te werken aan de ontwikkeling van eigen IOT-oplossingen. In deze functie ben je verantwoordelijk voor het bouwen van webapplicaties, apps en dashboards voor het uitlezen en managen van sensoren in machines. Je werkt nauw samen met een team van ontwikkelaars en engineers om de beste software-oplossingen te creëren. Jouw werkzaamheden zien er als volgt uit: Je bent in deze rol verantwoordelijk voor het ontwerpen, ontwikkelen en onderhouden van webapplicaties en softwaretoepassingen voor in-house ontwikkelde IOT oplossingen. Je werkt aan complexe databases en back-end

Bekijk vacature »

3D BIM Add-on Developer

As a 3D BIM add- on developer at KUBUS, you will develop add-ons (called BCF- Managers) to the leading building information modeling (BIM) programs Revit, Navisworks, Archicad, AutoCAD and Tekla Structures. BCF Managers enable data transfer between BIM software and BIMcollab. You will work on both the front- and the back-end. As a software company, KUBUS is in a unique position. We build our own products that are used by tens of thousands of users worldwide. Our company is just the right size: big enough to make a real impact in the market, but small enough that as an individual

Bekijk vacature »

React developer Inhouse cloudplatform

Functie De functie: Als front-end developer kom je te werken naast 2 andere front-end/React developers, waaronder één senior. Een hele mooie kans dus om in korte tijd veel nieuwe kennis en ervaring op te doen. Ze hebben momenteel veel werk hierin en daarom willen ze het team graag uitbreiden. Het is van belang dat je, zeker gezien het vele thuiswerken, in ieder geval al een aantal projecten hebt gedaan in React. Taken waar je aan kunt denken zijn het ontwikkelen van client-applicaties o.b.v. HTML5, React en andere open standaarden. Ook ben je nauw betrokken bij het implementeren van designs o.b.v.

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 »

Backend Developer Scrummaster .NET

Samengevat: Deze werkgever is een ambitieus internetbedrijf met een passie voor digitale communicatie. Ben jij geschikt als Backend Developer? Heb je ervaring met .NET platform? Vaste baan: Backend Developer / SCRUM Master Scrum HBO WO €3.800 - €6.000 Deze werkgever is een innovatief bedrijf met enthousiaste mensen die jarenlang ervaring hebben met het ontwikkelen internet- en intranetoplossingen. Wij houden van korte lijnen en open en eerlijke communicatie. Wij zetten graag onze jarenlange ervaring in om perfect werkende oplossingen te ontwikkelen. Wij ondersteunen dienstverlenende organisaties bij het ontwikkelen en realiseren van een effectief, adaptief communicatieplatform. Je ontwikkelt met ons de meest

Bekijk vacature »

Lead developer

Functie Als lead developer wordt jij verantwoordelijk voor een van onze development teams. Samen met de Software Architect bewaak jij de kwaliteit en uitvoering van onze complexe vraagstukken. Daarnaast ben jij verantwoordelijk voor het inschatten, designen en ontwikkelen van middelgrote tot grote veranderingen in de software. Ook coördineer jij het proces rondom complexe technische vraagstukken. Verder bestaat jouw takenpakket uit het volgende: – Het aansturen van jouw development team; – Het begeleiden van Junior Software Engineers; – Het maken van technische analyses m.b.t. nieuwe aanvragen en het tijdsbestek inschatten voor de uitvoering hiervan; – Het uitvoeren van de ontwikkeling van

Bekijk vacature »

Applicatie ontwikkelaar

Functie omschrijving Zelfstandige applicatie ontwikkelaar gezocht voor familiair bedrijf in omgeving Rotterdam! Ben jij op zoek naar een nieuwe uitdaging en zoek jij een informele werkgever waar je zelfstandig kunt werken binnen een leuk IT team, lees dan snel verder want wie weet zijn wij op zoek naar jou! Binnen deze rol houdt jij je met het volgende bezig: Onderhouden en ontwikkelen van de IT systemen; Opzetten van Azure Cloud systemen, denk aan interfaces, hardware op de Cloud, webportalen of BI functies; Werken aan scripts binnen verschillende software applicaties, denk aan ERP en CAD; Ontwikkelen en implementeren van MS PowerApps

Bekijk vacature »

Traineeship IT regio Amsterdam/Utrecht

Wat ga je doen? Het traineeship begint met een fulltime maand cursussen en praktijkdagen, waarin je de basis van het IT-vak leert op de Shared Servicedesk (SSD). Daarnaast ga je meteen aan de slag voor je eerste certificering! (ITILv4). Je start in een groep met 4 tot 10 deelnemers, waarmee jij gedurende die maand optrekt en je kennis kunt delen. Na het voltooien van de eerste maand ga je direct voor een langere periode aan de slag bij één van onze klanten of blijf je intern bij ons op de Shared Servicedesk. Je bent het eerste aanspreekpunt van de eindgebruikers

Bekijk vacature »

Senior .Net developer

Sogeti is een organisatie met een goede werksfeer en zo min mogelijk hiërarchische verhoudingen. Ga je bij ons als .Net Developer aan de slag? Dan werk je dagelijks met collega’s aan de mooiste IT-projecten. Deze snelgroeiende groep collega’s krijgt energie van hun vak en dat merk je op de werkvloer. Natuurlijk krijg jij de mogelijkheid je te certificeren. We organiseren regelmatig technische Meet-ups en doen we veel aan kennisdeling. Mede hierdoor zij wij dit jaar Microsoft Partner of the year geworden. Sogetisten staan klaar voor elkaar, hebben lol met elkaar en daarmee behalen we de mooiste resultaten! Werken bij Sogeti

Bekijk vacature »

Full Stack Java ontwikkelaar

Functieomschrijving Voor de politie zijn wij op zoek naar een Full stack Java ontwikkelaar. Als ervaren full stack Java ontwikkelaar binnen de gewenste deadlines meewerken aan de totstandkoming van de gewenste werkzaamheden. Taken Upgraden van GeoServer, SOLR, Oracle Spatial database, Tomcat Migreren Oracle Spatial naar PostgreSQL/PostGIS Migreren SOLR naar ElasticSearch Geografische gegevens op het interne netwerk beschikbaar maken Doorontwikkelen en actualiseren van de geografische services Het up to date brengen van de CI/CD pipeline, samen met medewerkers die verantwoordelijk zijn voor de CI/CD tooling Aanspreekbaar op de solution architectuur en stemt die met collega's in het cluster Geo De opdracht

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

08/11/2024 05:16:57
 
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.