Share
SQL is nog een andere essentiële taal voor ontwikkelaars die datagestuurde websites willen maken. Veel ontwikkelaars zijn echter onbekend met verschillende aspecten van SQL; dus in dit artikel analyseren we tien essentiële tips.
Webontwikkelaars hebben vaak een overvloed aan talen tot hun beschikking. Het is cruciaal voor ontwikkelaars om de juiste taal voor de taak te gebruiken.
Laten we de volgende code doornemen. In het eerste voorbeeld selecteert de ontwikkelaar alle kolommen en alle rijen uit de klantentabel. In het tweede voorbeeld selecteert de ontwikkelaar alleen de voornaam, achternaam en adres uit de klantentabel voor een enkele klant met ID 1001. Niet alleen beperkt de tweede query de kolommen die worden geretourneerd, maar ook beter.
SELECTEER * VAN klant;
SELECT firstName, lastName, shippingAddress FROM klant WHERE klantID = 1001;
Wanneer u code schrijft, zorg er dan voor dat deze efficiënt werkt.
Te veel ontwikkelaars zijn tevreden met de code die voldoende presteert op 100 rijen gegevens, met weinig aandacht aan de tijd wanneer de database 10.000 rijen zal hebben.
Databases slaan waardevolle informatie op. Vanwege dit feit zijn databases vaak het belangrijkste doelwit voor aanvallen. Veel ontwikkelaars weten niet dat hun code kritieke beveiligingsproblemen heeft, wat niet alleen voor klanten, maar ook voor u een heel eng feit is. Momenteel kunnen ontwikkelaars juridisch aansprakelijk worden gesteld als hun eigen persoonlijke nalatigheid resulteert in een databasebeveiligingsrisico dat vervolgens wordt misbruikt.
In het geval dat u niet overtuigd bent van de ernst van databasebeveiliging, zouden deze twee artikelen ertoe moeten bijdragen het punt naar huis te nemen:
"De FBI en de Virginia State Police zijn op zoek naar hackers die eisten dat de staat hen donderdag een losgeld van $ 10 miljoen zou betalen voor de teruggave van miljoenen persoonlijke farmaceutische gegevens waarvan zij beweren dat ze die hebben gestolen uit de geneesmiddelendatabase van het land."
Lees het artikel in de Washington Post"Kaspersky Lab, een in Moskou gevestigd beveiligingsbedrijf, heeft vandaag toegegeven dat een database met klantinformatie bijna 11 dagen lang werd blootgesteld en dat het alleen de schending te weten kwam toen Roemeense hackers het bedrijf er afgelopen zaterdag over berichtten."
Lees het ComputerWorld-artikel
Laten we een ander voorbeeld bekijken met behulp van pseudo-code.
Accentsconagua
// Theoretische code txtUserName.setText ("eshafer 'OR 1 = 1"); query = "SELECT gebruikersnaam, wachtwoord FROM gebruikers WHERE gebruikersnaam = '" + txtUserName.getText () + "';"; // Laatste vraagquery = "SELECT gebruikersnaam, wachtwoord van gebruikers WHERE gebruikersnaam = ejshafer OR 1 = 1;" Hopelijk heb je naar die code hierboven gekeken en de kwetsbaarheid opgemerkt. De query zal uiteindelijk alle gebruikersnaam- en wachtwoordrecords uit de tabel selecteren, omdat 1 altijd gelijk is aan 1. Nu bereikt dit specifieke voorbeeld niet veel voor de zogenaamde hacker. Er zijn echter bijna onbegrensde mogelijkheden voor extra schadelijke code die kan worden toegevoegd met catastrofale resultaten.
De oplossing is vaak DBMS-specifiek; dat wil zeggen, het varieert tussen MySQL, Oracle of SQL Server. In PHP met MySQL is het bijvoorbeeld gebruikelijk om parameters te verlaten met behulp van de functie mysql_real_escape_string voordat de SQL-query wordt verzonden. Als alternatief kunt u voorbereide uitspraken gebruiken om uw vragen "voor te bereiden". Maak er uw missie van om de DBMS waarmee u werkt en de inherente beveiligingsproblemen te begrijpen.
SQL-injectie is niet het enige beveiligingsprobleem waar databases en ontwikkelaars zich zorgen over kunnen maken, maar het is een van de meest voorkomende aanvalsmethoden. Het is belangrijk om uw code te testen en bekend te zijn met de nieuwste beveiligingsproblemen voor uw DBMS om u te beschermen tegen aanvallen.
Enkelvoudige SQL-selecties voor tabellen zijn vrij eenvoudig te schrijven. Zakelijke vereisten vereisen echter vaak dat complexere query's moeten worden geschreven. Bijvoorbeeld: "vind alle bestellingen voor elke klant en toon de producten voor elke bestelling". In deze specifieke situatie is het waarschijnlijk dat er een klantentabel, een ordertabel en een orderregeltabel is (de laatste zou zijn om een mogelijke veel-op-veel-recordrelatie op te lossen). Voor degenen die iets meer bekend zijn met SQL, is het snel duidelijk dat een tabel join, eigenlijk twee tabel joins nodig zijn voor deze query. Laten we eens naar een voorbeeldcode kijken.
SELECT customer.customerID, order.order_id, order_lijn.order_item VAN klant BINNEN JOIN bestelling AAN klant.klantID = bestelling.klantID BINNEN JOIN volg orde OP Bestel.orderID = bestelregel.
Oke, eenvoudig genoeg. Voor degenen die niet weten, bovenstaande code is een innerlijke join. Meer specifiek, de bovenstaande code is een equi-join.
Laten we de verschillende soorten joins definiëren.
Innerlijke joins: het belangrijkste doel van inner joins is het retourneren van overeenkomende records.
Buitenste joins: voor outer joins is niet vereist dat elke record een overeenkomende record heeft.
Met dank aan Ronald Erdei voor de afbeeldingen.
Er is nog een laatste type join dat moet worden beschouwd, wat een self-join is. Een self-join is slechts een join van een tabel naar zichzelf.
EMPLOYEE-TABEL - Medewerkernaam-CommissarisID
In deze situatie is een self-join vereist om te bepalen welke werknemers worden gecontroleerd door een bepaalde medewerker.
Hopelijk verduidelijkt dit de basisbeginselen van joins, omdat dit een van de belangrijkste functies van SQL is, waardoor het zo'n krachtige databasetaal is. Zorg ervoor dat u de juiste join gebruikt voor uw specifieke situatie.
In SQL heeft meestal elke tabelkolom een gekoppeld gegevenstype. Tekst, Integer, VarChar, Date en meer, zijn meestal beschikbare typen voor ontwikkelaars om uit te kiezen.
Zorg er bij het ontwikkelen voor dat u het juiste gegevenstype voor de kolom kiest. Datums moeten DATE-variabelen zijn, getallen moeten een numeriek type zijn, enz. Dit wordt vooral belangrijk als we een later onderwerp behandelen: indexering; maar ik zal een voorbeeld laten zien van slechte kennis van datatypes hieronder:
SELECT employeeID, employeeName FROM employee WHERE employeeID = 112457891;
Ziet er goed uit op basis van wat we momenteel kennen, correct? Wat als employeeID eigenlijk een string is. Nu hebben we een probleem, omdat de DBMS mogelijk geen overeenkomst vindt (omdat datatypen en gehele getallen verschillende typen zijn).
Daarom, als u indexering gebruikt, zult u waarschijnlijk verbijsterd zijn over waarom uw vraag voor altijd duurt, wanneer het een eenvoudige indexscan zou moeten zijn. Dit is de reden dat ontwikkelaars speciale aandacht moeten besteden aan datatypes en hun toepassingen. Niet-sleutelkenmerken die ID's zijn, zijn vaak tekenreeksen, in tegenstelling tot gehele getallen, vanwege de toegenomen flexibiliteit die wordt verleend. Dit is echter ook een probleemgebied voor junior-ontwikkelaars, die ervan uitgaan dat ID-velden gehele getallen zijn.
Het correct gebruiken van datatypen is essentieel voor een goede databaseprogrammering, omdat deze direct leiden tot query-efficiëntie. Efficiënte query's zijn essentieel voor het creëren van hoogwaardige, schaalbare applicaties.
Alle programmeertalen hebben standaarden die webontwikkelaars moeten kennen en SQL is niet anders. SQL werd gestandaardiseerd door ANSI en vervolgens ISO, waarbij af en toe nieuwe revisies van de taal werden ingediend. De laatste revisie is SQL: 2008, hoewel de belangrijkste revisie waarvan ontwikkelaars op de hoogte moeten zijn SQL is: 1999. De herziening van 1999 introduceerde recursieve query's, triggers, ondersteuning voor PL / SQL en T-SQL en een paar nieuwere functies. Het definieerde ook dat de JOIN -instructies in de FROM-clausule worden gedaan, in tegenstelling tot de WHERE-component.
Bij het schrijven van code is het belangrijk om in gedachten te houden waarom normen-compatibele code nuttig is. Er zijn twee primaire redenen waarom normen worden gebruikt. De eerste is onderhoudbaarheid en de tweede is platformonafhankelijke platformonafhankelijkheid. Net als bij desktoptoepassingen wordt ervan uitgegaan dat websites een lange levensduur hebben en verschillende updates zullen doorlopen om nieuwe functionaliteit en reparatieproblemen toe te voegen. Zoals elke systeemanalist u zal vertellen, geven systemen het grootste deel van hun levensduur door aan de onderhoudsfase. Wanneer een andere programmeur uw code in 2, 5 of 10 jaar benadert, kunnen ze dan nog steeds begrijpen wat uw code doet? Normen en opmerkingen zijn ontworpen om de onderhoudbaarheid te bevorderen.
De andere reden is platformonafhankelijke functionaliteit. Met CSS is er momenteel een strijd tussen standaarden tussen Firefox, Internet Explorer, Chrome en andere browsers over de interpretatie van code. De reden voor de SQL-standaarden is om een vergelijkbare situatie tussen Oracle, Microsoft en andere SQL-varianten zoals MySQL te voorkomen.
Database-normalisatie is een techniek om de inhoud van databases te ordenen. Zonder normalisatie kunnen databasesystemen onnauwkeurig, traag en inefficiënt zijn. De gemeenschap van databaseprofessionals heeft een reeks richtlijnen ontwikkeld voor het normaliseren van databases. Elk 'niveau' van normalisatie wordt een vorm genoemd en er zijn 5 vormen, totaal. De eerste normale vorm is het laagste niveau van normalisatie, tot de vijfde normale vorm, wat het hoogste niveau van normalisatie is.
In de realiteit van database-ontwikkeling is het overstappen naar 3NF de belangrijkste sprong. 4NF en 5NF zijn een beetje meer een luxe (en soms een last) in database-ontwikkeling en worden in de praktijk zelden gezien. Als je worstelt met de concepten, of de eerste drie vormen onthoudt, is er een eenvoudige relatie. "De sleutel, de hele sleutel en niets anders dan de sleutel.", Die betrekking heeft op 1NF, 2NF en 3NF.
Nu, zonder al te ver te gaan in de database-theorie, laten we ons gewoon richten op de voordelen van normalisatie. Naarmate de gegevens door de normalisatieformulieren vordert, wordt het schoner, beter georganiseerd en sneller. Nu, met een kleine database die slechts 5 tabellen en 100 rijen gegevens heeft, zal dit niet snel duidelijk zijn. Naarmate de database groeit, zullen de effecten van normalisatie echter veel duidelijker worden met betrekking tot snelheid en behoud van gegevensintegriteit. Er zijn echter enkele situaties waarin normalisatie geen zin heeft, zoals wanneer het normaliseren van de gegevens te ingewikkeld vragen zal creëren die nodig zijn om de gegevens te retourneren.
Dit is een algemeen genegeerd punt; in feite heeft alle voorbeeldcode die ik in deze tutorial heb gedemonstreerd in wezen deze tip geschonden. Qua databaseontwikkeling ziet een volledig gekwalificeerde objectnaam er als volgt uit: DATABASE.schema.TABLE. Laten we nu kijken waarom volledig gekwalificeerde namen belangrijk zijn, en in welke situaties ze nodig zijn. Het doel van een volledig gekwalificeerde objectnaam is om dubbelzinnigheid te elimineren. Beginnende ontwikkelaars hebben zelden toegang tot meerdere databases en schema's, wat de problemen in de toekomst compliceert. Wanneer een bepaalde gebruiker toegang heeft tot meerdere databases, meerdere schema's en de tabellen daarin, wordt het cruciaal om direct op te geven waartoe de gebruiker toegang probeert te krijgen. Als u een tabel voor medewerkers heeft, heeft uw baas een tabel voor medewerkers en het schema waarop uw webtoepassing wordt uitgevoerd, heeft een tabel voor medewerkers, die u echt probeert te openen?
Logischerwijs zou de volledig gekwalificeerde naam er uitzien als DATABASE.SCHEMA.OBJECTNAME, echter, syntactisch (dat wil zeggen in uitvoerbare instructies), het zou gewoon SCHEMA.OBJECTNAME zijn. Hoewel verschillende DBMS-versies verschillende syntaxisverschillen hebben, is de bovenstaande stijl algemeen van toepassing.
-- Niet "SELECT * FROM table" SELECT * FROM schema.TABLE
Het volledig kwalificeren van uw databasenamen is belangrijk wanneer u werkt met databases die groter zijn en door meerdere gebruikers worden gebruikt en meerdere schema's bevatten. Het is echter een goede gewoonte om erin te komen.
Een database-index is een gegevensstructuur die de snelheid van bewerkingen in een databasetabel verbetert. Indexen kunnen worden gemaakt met behulp van een of meer kolommen van een databasetabel, die de basis vormen voor zowel snelle willekeurige opzoekingen en efficiënte toegang van geordende records. Indexeren is ongelooflijk belangrijk bij het werken met grote tabellen, maar af en toe moeten kleinere tabellen worden geïndexeerd, als ze naar verwachting zullen groeien. Kleine tabellen die klein blijven, moeten echter niet worden geïndexeerd (als uw boek bijvoorbeeld 1 pagina is, is het dan logisch om naar de index te gaan)?
Veel ontwikkelaars schrijven hun code en testen deze op een tabel met 10 of 100 rijen en zijn tevreden wanneer hun code voldoende presteert. Naarmate de tabel groeit naar 10.000 of 1.000.000 rijen, vertraagt de code echter tot een slakkengang en kan de client net zo goed op lunch gaan wachten tot de code wordt uitgevoerd.
Wanneer een query in een database naar een overeenkomende record zoekt, zijn er twee manieren waarop de zoekopdracht kan worden uitgevoerd.
Het is belangrijk om te onthouden dat indexen af en toe opnieuw moeten worden opgebouwd, omdat gegevens aan de tabel worden toegevoegd. Bovendien, terwijl indexen de toegang tot gegevens verbeteren, vertraagt het de wijziging van gegevens. Vanwege dit hebben de meeste DBMSes een optie om een index tijdelijk uit te schakelen om massamodemodificatie mogelijk te maken, en dan toe te staan dat deze opnieuw wordt ingeschakeld en later opnieuw wordt opgebouwd.
Wanneer u met een database met meerdere gebruikers werkt, is het belangrijk om verschillende databasemachtigingen goed af te handelen. Het is duidelijk dat de meeste databases een beheerder hebben, maar heeft het altijd zin om uw query's uit te voeren als de beheerder? Wilt u bovendien al uw junior ontwikkelaars en gebruikers uw beheerdersreferenties geven om hun vragen te kunnen stellen? Hoogstwaarschijnlijk niet. De verschillende mogelijke machtigingen voor uw database zijn afhankelijk van uw DBMS, maar er zijn gemeenschappelijke thema's tussen deze.
In MySQL, bijvoorbeeld, zal het typen van "TABELLEN WEERGEVEN" een lijst met tabellen in uw database onthullen, waarvan u waarschijnlijk een 'gebruikerstabel' zult opmerken. Als u 'DESC-gebruiker' typt, wordt zichtbaar dat er verschillende velden in de gebruikerstabel staan. Naast een host, gebruikersnaam en wachtwoord, is er ook een lijst met privileges die voor een gebruiker kan worden ingesteld. Daarnaast is er een 'db'-tabel die meer rechten voor een specifieke database regelt.
SQL Server biedt de opdrachten GRANT, DENY en REVOKE om machtigingen van een gebruiker of rol op te geven of weg te nemen. Bovendien biedt SQL Server rollen zoals db_writer, db_reader. Vaak kennen onwetende ontwikkelaars deze rollen (in tegenstelling tot het creëren van hun eigen, aangepaste rollen) toe aan andere gebruikers, wat resulteert in een algemene verlaagde databasebeveiliging, evenals de mogelijkheid dat een gebruiker een ongewenste bewerking uitvoert.
Het correct beheren van de machtigingen van uw databasegebruiker is essentieel voor het beheer van niet alleen beveiliging, maar biedt ook een basis voor snellere ontwikkeling en bescherming van gegevensintegriteit.
Databases zijn krachtige hulpmiddelen, maar ze zijn niet onbeperkt. Oracle, SQL Server en MySQL hebben allemaal unieke beperkingen voor zaken als maximale databasegrootten, maximaal aantal tabellen en andere. Veel ontwikkelaars kiezen onbewust een DBMS-oplossing voor hun project zonder te plannen of rekening te houden met de latere vereisten van hun database.
Raadpleeg de DBMS-handleiding voor de verschillende beperkingen, bijvoorbeeld SQL Server-beperkingen bevinden zich op de MSDN-website: http://msdn.microsoft.com/en-us/library/ms143432.aspx
In dit artikel hebben we 10 essentiële tips voor SQL-ontwikkelaars besproken. Er zijn echter veel andere nuttige SQL-technieken die kunnen worden genoemd; dus laat alsjeblieft je gedachten achter in de reacties, of je denkt dat dit artikel alle essentiële onderwerpen behandelt, of je denkt dat er een is weggelaten. Blijf ontwikkelen en onthoud dat de code die je schrijft de internetinfrastructuur ondersteunt, en zonder jou zou internet niet zo succesvol zijn als het is.
