Download van Internet

Status
Niet open voor verdere reacties.

JJZijlstra

Gebruiker
Lid geworden
26 nov 2013
Berichten
283
Beste lezer(s),

Graag zou ik meer willen weten van SQL. Hierover heb ik een paar vragen en zijn er dingen die ik niet helemaal begrijp. Graag het volgende:

-- Van welke link of URL kan ik SQL downloaden en vrij gaan gebruiken.
-- Ook lees ik dat er een relatie moet(?) bestaan tussen een server en mezelf, hoe zit dat precies. Dit lees ik wanneer terecht kom op de site van Microsoft.
-- Als ik er mee kan werken, waar kan ik een goede tutorial vinden?

Met belangstelling wacht ik uw reactie verder af.

Vriendelijke groet,
Toby
 
SQLexpress is gratis, en gratis te downloaden bij Microsoft

Tutorials op bijv. w3schools.com
 
De vraag is: Wat wil je met SQL doen, en waar wil je het in gaan gebruiken? SQL is niets meer dan een standaardtaal om databases te beheren waarbij er diverse soorten databases van zijn:
MySQL, MariaDB, SQLlite, msSQL, MS Access, Oracle etc......

Aan de hand van je doel en operatingsystem kan je vervolgens bepalen hoe en wat.
 
Laatst bewerkt:
De bedoeling is om gewoon wat te oefenen met gegevens uit bijv. een excel database.
Overeenkomstig afhankelijk van de commando's zou ik in het sql-programma de gewenste database-gegevens moeten krijgen.
Toen ik naar de Microsoft-pagina ging kreeg ik een opsomming van allerlei mogelijkheden, zie foto's bijlage.
Ook op mijn C-schijf staan een flink aantal "SQL"-downloads die misschien niet allemaal nodig zijn.
Ik weet echt niet hoe ik hier verder mee moet.
Graag hoor ik nader.

Vriendelijke groet,
Toby
 

Bijlagen

  • ScreenHunter_118 Jul. 05 10.35.jpg
    ScreenHunter_118 Jul. 05 10.35.jpg
    110,7 KB · Weergaven: 60
  • ScreenHunter_117 Jul. 05 10.34.jpg
    ScreenHunter_117 Jul. 05 10.34.jpg
    107,1 KB · Weergaven: 56
Laatst bewerkt:
Excel is geen database, maar een spreadsheet. Je kan er voor zover ik zie wel data mee uit een database overpompen.

Als je echt met databases wilt spelen zou ik met MS Access spelen, of als je van webdevelopping houdt: MariaDB of MySQL als server en HeidiSQL of phpMyAdmin als client.
 
Dank u heren, ik zal hier in alle rust eens naar gaan kijken en als ik iets niet weet of ergens uit kom, dan horen of lezen jullie dat van mij.

Vriendelijke groet,
Toby
 
De vraag blijft: in wat voor omgeving wil je nou met databases werken? Aan de hand van het beantwoorden op deze vraag maak je de keuze voor welke database je kiest. En en dan is de vraag: In welk programma je de data wilt binnenhalen.
 
Hoewel ik weet dat Excel een spreadsheet is, gebruik ik deze als database voor mijn gegevens. Access zou misschien een betere optie zijn, maar ik heb nu eenmaal voor Excel gekozen.
Ik hoop je eerste vraag hiermee te hebben beantwoord.

Dan je tweede vraag: In welk programma zou je de database willen binnenhalen. Het lijkt me voor de hand liggend dat ik voor Excel dat ik de zojuist gedownloade "mysql-installer-community-5.7.22.1.msi" moet gaan installeren. Is dit juist?

Graag hoor ik nog.

Vriendelijke groet,
Toby
 
Verdiep je eerst eens in welke server het beste uitkomt voor je doeleinden.

Excel werkt samen met MsSQL en niet direct met MySQL. Ga niet eerst wat aanrommelen, maar zet eerst op een rij wat er mogelijk is met Excel en hoe je dat kan bewerkstelligen. Straks heb je diverse soorten SQL-servers draaien die je PC vervuilen.
 
Laatst bewerkt:
Dank je voor je reactie. Ik zal hier enige tijd voor gaan uittrekken en kijken hoe een en ander in elkaar steekt.
Daarna zal ik misschien nog wel met vragen komen.

Vriendelijke groet,
Toby
 
Excel heeft zeer beperkte database functionaliteit, het is geen database. Een database kan je namelijk met meerdere gebruikers tegelijk benaderen voor het opslaan en uitlezen van data, daar is Excel niet voor gemaakt.

Access is geschikt als stand-alone database op je pc. Access heeft zowel de database als de weergave/rapportage functionaliteit, een alles in één dus. Je kan Access bij lage gebruiksbelasting tot 3 gebruikers tegelijk gebruiken door een Access database bestand op een netwerkschijf te zetten en op iedere pc het Access programma te installeren die je elk koppelt met het centrale bestand. Je hebt dan geen SQL server nodig terwijl je toch met (MS) SQL kan werken. Om te leren prima maar niet geschikt voor productie omgevingen.

Op internet wordt MySQL het meest gebruikt, behalve bij grote bedrijven, die gaan over op zwaardere databases zoals Oracle.
MySQL is een database server maar daarbij heb je ook nog software nodig voor het opslaan en opvragen van data. Dit kan met een internet applicaties op een webserver maar ook vanuit Access, diverse SQL applicaties of SQL tools. Wil je MySQL aan Access koppelen dan kan je dat doen via ODBC vauit Access, dan is MySQL de backend (database) en Access de frontend (weergave/rapporten).

Overal waar ik database typ bedoel ik een (R)DBMS.
Access is een DBMS met toegevoegde RDBMS functionalitiet.
MySQL / MS SQL / MariaDB / Oracle / etc zijn een RDBMS.

Excel zou je kunnen zien als een DBMS met beperkte functionaliteit
 
Laatst bewerkt:
@Bron,

Hartelijk dank voor de uitgebreide en duidelijke informatie.
Hoewel ik wist dat Access een beter databaseprogramma is was ik toch uitgegaan van Excel ondanks zijn beperkte functionaliteit.

Je overtuigt mij nu hiermee om voor databases voortaan Access te gaan gebruiken. Dat ga ik dan ook doen.
Voordat ik verder ga met mijn zgn. "sql-perikelen" ga ik eerst met Access aan de slag. Hiermee heb ik nog niet zoveel ervaring.
Op een later tijdstip zal ik dan waarschijnlijk terugkomen op het sql-gebeuren maar dan vanuit Access en gebruik ik de instructies die je mij hebt gegeven.

Vriendelijke groet,
Toby
 
Het is voor mij al weer een tijdje terug dat ik met Access werkte maar dit is het in het kort

- maak een "nieuwe database", geef deze een naam en dan opslaan.
- maak in Ontwerpweergave enkele tabellen met velden (elke tabel heeft een primaire sleutel).
- sluit alle tabellen en ga dan naar Relaties en maak relaties/joins tussen de tabellen.
- vul de tabellen met wat data om te testen.
- dan naar Queryontwerp om een query te maken (in grafische vorm of in SQL tekst vorm).
 
@bron,

Hartelijk dank voor je heldere puntsgewijze uitleg. Hier heb ik zeker iets aan gehad.
Zelf was ik ook al op deze werkwijze gekomen en met succes.

Het volgende en wel moeilijke item is de normalisatie. Hier ben ik op dit moment mee bezig om e.e.a. te lezen en internetfilmpjes te bekijken.
Natuurlijk lees ik ook de uitgebreide informatie van OktaFish.
Zoals ik het tot nu toe begrijp is dit dé manier om de zgn. "primary key" te vinden. Heb ik dat juist?
Het lijkt me verstandig om eerst deze theorie goed te begrijpen en dan verder te gaan met Access.
Als het anders is dan hoor ik dat graag.

Vriendelijke groet,
Toby
 
Normaliseren betekent met name het voorkomen van dubbele gegevens in de database. Voordat je het ontwerp in Access zet kan je eerst een overzicht maken van alles wat je wilt opslaan, dan zie je al gauw waar dubbele gegevens worden bijgehouden en die zet je in een aparte tabel.

Wat betreft de primary key kan je het jezelf makkelijk maken door elke tabel als eerste het veld "tabelnaamID" te geven, bijvoorbeeld tabel Klanten: KlantID, tabel Orders: OrderID, tabel Producten: ProductID, enz. Na het maken van de relaties kan je alle tabellen overal realtioneel gebruiken.

Soms lijkt een "primair veld" geschikt om als primary key te gebruiken maar kan achteraf problemen geven omdat
1. je de veldwaardes wilt kunnen wijzigen, bijv. op 1 januari verandert het factuurnr van 2018xxx naar 2019001
2. in de toekomst een conflict kan ontstaan in de veldwaardes, bijv. [1, M, heer ] en [ 2, V, mevrouw ]
Je zou de primary key (1e veld) weg kunnen laten omdat M en V (2e veld) geschikt zijn als primary key. Maar wat als er volgend jaar een wet komt dat ook de gender "VanAllesWat" (V) bijgehouden moet worden? Daarom is het gewoon handig altijd een aparte primairy key (autonummering) te gebruiken die je alleen gebruikt in je relaties.
 
Laatst bewerkt:
@Bron,

Al lezende uit jouw verhaal en ook nadat ik wat hoofdstukken over de normalisatie heb gelezen kwam ik zelf tot de volgende conclusie.

Misschien is het verstandig om bij het maken van verschillende tabellen verschillende velden te maken van gegevens die je nodig hebt, daarbij opgemerkt dat een bepaald veld van de ene tabel beslist niet nog eens in een andere tabel mag voorkomen.
Een verplichte uitzondering hierop is de zgn. Primary Key die nodig is om de relaties tussen de tabellen tot stand te brengen.
Als ik het goed begrijp zou de "Primary Key" het beste een getal kunnen zijn die je qua duidelijkheid aangeeft met "ID" op het eind, bv. ProductID. Vergissen lijkt me dan uitgesloten.

Het lijkt me dat ik met bovengenoemde werkwijze de ietwat ingewikkelde theorie over normalisatie vanaf het prille begin direct kan omzeilen bij het inrichten van een database of vergis ik me?
Wél zal ik alle informatie over normalisatie en overeenkomstige werkwijze blijven volgen op internet.

Graag hoor ik nog.

Vriendelijke groet,
Toby
 
Je hebt het helemaal goed :thumb:
Gebruik voor de primary key de auto-teller, dat is gebruikelijk.
 
Soms lijkt een "primair veld" geschikt om als primary key te gebruiken maar kan achteraf problemen geven...
De uitleg van bron is op zich duidelijk en correct genoeg, maar hier gaat het toch een beetje fout. “Primair veld” is niets meer en niets minder dan de vertaling van het Engelse “Primary Key”. En dat bestempelt het verhaal uiteraard als een beetje onzin. Een Primaire sleutel is per definitie ‘het minimale aantal velden dat nodig is om precies één record uniek te identificeren’. In een tabel met adressen is dat in Nederland een combinatie van minstens twee gegevens: postcode en huisnummer. Maak je daar een sleutel van, dan heb je dus een goede primaire sleutel gemaakt. Je kunt uiteraard ook een sleutel maken van de velden [Postcode], [Huisnummer] en [Straatnaam], maar dan heb je wel een sleutel (de combinatie is immers nog steeds uniek) maar geen primaire omdat er een overbodig veld in de sleutel zit.

Als je tabellen gaat koppelen met een één-op-veel relatie (relaties zijn overigens niet nodig of verplicht), dan moet de volledige sleutel in de koppeltabel zitten, anders werkt de relatie niet. Primaire sleutels op basis van meerdere velden zijn dan niet handig. Daarom wordt vaak een Autonummerveld (in Access) dat immers altijd uniek is, en dus prima als Primaire sleutel gebruikt kan worden. Autonummervelden zijn weer minder handig als het veld niet sequentieel is, zoals sleutels die op jaarbasis worden gemaakt. Dan gebruik je dus een normaal (numeriek of tekst) veld, dat je handmatig of met een functie vult. Er is dus functioneel gezien geen verschil tussen een Autonummerveld of een gewoon veld. Elke sleutel moet uniek zijn en mag geen lege waarden of dubbele waarden bevatten. Hoe je dat bereikt, is redelijk onbelangrijk.

Ik hoop dat het nu wat duidelijker is :). In ieder geval is dit de juiste uitleg :D
 
In ieder geval is dit de juiste uitleg.
Vreemd, je begint in je verhaal dat mijn uitleg duidelijk en correct is en je eindigt met deze zin? Een uitgebreide uitleg over de Primary Key is overbodig, dit is TS allang duidelijk vermoed ik. Postcode en huisnummer zijn tezamen niet uniek, met een veld "huisnummer-toevoeging" wel. Voor een goede performance is het onzin om de straatnaam in de primairy key op te nemen.

Autonummervelden zijn weer minder handig als het veld niet sequentieel is
In de praktijk (zoals in webshops) wordt meestal in elke tabel een autonummering ID veld als primary key opgenomen, of je 'm wel of niet gebruikt doet er niet toe. Andere velden die je vaak nodig hebt in queries worden dan geindexeerd.
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan