[SQL] Inserten leeg veld zonder haakjes

[Verwijderd]

Dit zal vast een hele domme vraag zijn maar ik stel hem toch omdat ik al een hele tijd aan het zoeken en proberen ben en er niet achter kan komen.

Bij het inserten van onderstaande query in PostGreSQL komen op de plek van de lege velden (stel dat phone leeg is) twee enkele haakjes te staan in de database. Terwijl als een veld gevuld is de haakjes er niet staan, terwijl ze wel nodig zijn ivm met spaties enzo. En zonder de haakjes gaat hij ook zeuren dat de kolom niet bestaat.

code:

$query = "INSERT INTO customer (customerid, firstname, company, lastname, 
streetaddress, city, postalcode, country, phone, fax, email) VALUES ('4', '".$billing
['firstname']."', '".$billing['company']."',    '".$billing['lastname']."', '".$billing
['streetaddress']."', '".$billing['city']."', '".$billing['postalcode']."', '".$billing
['country']."', '".$billing['phone']."', '".$billing['fax']."', '".$billing['email']."')";

Alle velden zijn van het type text.

Heeft iemand een suggestie wat ik fout doe?

[TRON]

Welke haakjes krijg je te zien? Enkele ( ' ) of dubbele ( " )?

[whoami]

Waarom zijn die velden text? Dat is totaal niet nodig, en slecht voor de performance.
Maak er maar VARCHAR van.

[Verwijderd]

Ik krijg enkele haakjes te zien, 2 stuk

Het gaat er niet om of het text of varchar is, dat moet ik nog veranderen. Met varchar treed precies hetzelfde probleem op.

[whoami]

Ik zeg ook niet dat dat de oplossing voor je probleem is, ik zeg gewoon dat je er beter zowiezo VARCHAR van maakt.

Om de oplossing van je probleem te kennen: kijk eerst eens hoe dat sql statement eruit ziet voor je het uitvoert; print het eens op het scherm.
Als er quotes in komen te staan, dan zal jij die wel in je DB zetten.

[Verwijderd]

Ik denk dat ik de oplossing al gevonden heb... Het programma die ik gebruik om de database te beheren plakt ze ervoor als hij leeg is.. als ik via psql een query opvraag is het goed... (heb er een uur over gedaan voor tot deze ontdekking te komen )

Over die performance heb je gelijk, zal het ff aanpassen (ik begin altijd erg ranzig te programmeren en ik verbeter het stukje bij beetje)

[Soultaker]

Zo erg is het ook weer niet om een TEXT veld te gebruiken hoor. Als je een database gebruikt vooral voor de organisatie van je gegevens en niet omdat je nou zo achterlijk veel gegevens hebt dat ze per se in een database moeten, dan kan ik me goed voorstellen dat performance niet je primaire zorg is. Dit soort optimalisaties kun je later nog wel uitvoeren. Het lijkt me sterk dat je met een stuk of 1000 klanten ooit enig verschil zal merken.

[whoami]

Je kan geen index op een TEXT veld leggen afaik.
Als je dan ff een querietje doet op klantnaam ofzo, dan kan dat nogal wat tijd in beslag nemen.

[Soultaker]

Je kunt zeker wel een index leggen op een TEXT veld. Ik zou ook niet weten waarom niet; waarden in een text field zijn gewoon comparable en hashable. Als performance echt belangrijk wordt is het waarschijnlijk wel beter om VARCHAR te gebruiken omdat dat toch weer scheelt bij het updaten en uitlezen van waarden, maar zolang je niet precies weet hoe groot je strings zullen zijn (of als de maximale en gemiddelde lengte van je strings erg veel verschillen) is er niet direct een noodzaak om VARCHAR te gebruiken. Het TEXT type is wat mij betreft dus niet per definitie taboe.

[whoami]

Ik weet niet hoe het zit bij andere DBMS'en, maar bij SQL Server kan je geen 'gewone' index maken op een TEXT veld. Daar zal je zowiezo mbhv full text indexing/searching aan de slag moeten gaan.

Columns consisting of the ntext, text, or image data types cannot be specified as columns for an index. In addition, a view cannot include any text, ntext, or image columns, even if they are not referenced in the CREATE INDEX statement.

Ik zeg ook niet dat TEXT velden taboe zijn, echter in dit geval zijn ze overkill en zeker niet de beste oplossing. Een TEXT veld gebruik je imo enkel als je er een lap tekst in kwijt wil, zonder dat je weet wat de max. lengte zal zijn.

[ Voor 23% gewijzigd door whoami op 06-05-2004 14:33 ]

[Soultaker]

In PostgeSQL kan het wel (ik heb het net getest). In MySQL ook, maar ik geloof dat je dan een prefix length op moet geven (je legt dan een index op de eerste X karakters van het veld).

Verder blijft het denk ik een kwestie van smaak en de situatie waarin je je bevindt. Ik vind dat je niet al te vroeg met dit soort performance tuning moet beginnen, tenzij je van het het begin af aan ontwerpt voor performance. Het is gewoon irritant als blijkt dat je je VARCHAR veld te groot of te klein hebt gekozen; je kunt dan net zo goed met TEXT beginnen en als je database gevuld is met praktijkgegevens het veld converteren naar een geschikt type.

Maar goed, als je bereid en in staat bent van het begin af aan goede inschattingen te maken van de beperkingen die je aan de gegevens in je database wilt opleggen en dus direct VARCHAR's van een geschikte grootte kunt kiezen, dan is daar op zichzelf natuurlijk weinig mis mee.

[whoami]

Soultaker schreef op 06 mei 2004 @ 14:46:
maar ik geloof dat je dan een prefix length op moet geven (je legt dan een index op de eerste X karakters van het veld).

Best logisch.

Verder blijft het denk ik een kwestie van smaak en de situatie waarin je je bevindt. Ik vind dat je niet al te vroeg met dit soort performance tuning moet beginnen, tenzij je van het het begin af aan ontwerpt voor performance.

Dat heeft eigenlijk in de eerste plaats niets met performance tuning te maken.
Het is gewoon het feit dat je het beste veldtype moet kiezen voor ieder veld, en een TEXT veld vind ik nu eenmaal niet het beste data-type voor een naam bv.

Het is gewoon irritant als blijkt dat je je VARCHAR veld te groot of te klein hebt gekozen; je kunt dan net zo goed met TEXT beginnen en als je database gevuld is met praktijkgegevens het veld converteren naar een geschikt type.

Tja, een VARCHAR kan je ook nog altijd vergroten/verkleinen, en een varchar kan voor de meeste doeleinden ook wel groot genoeg zijn. (In Oracle is de max. lengte voor een varchar2 4000 tekens, in SQL Server is dat 8000 dacht ik).

Trouwens, bij het creeëren van je database moet je in SQL Server al aangeven hoe groot je data-file moet zijn, wat het growing percentage, etc.... is. Die dingen bepaal je onder andere op de recordgrootte, en op de verwachte groei van de DB.
Het is dus eigenlijk wel nodig dat je al van bij de creatie van je DB eens goed nadenkt over de velden en hun data-type.
Dit zijn dingen die in de analyse-fase naar voren moeten komen. Als je je DB maakt, en je maakt van ieder alfanumeriek veld zomaar een TEXT veld met de instelling van 'we zien later wel of we het naar een (var)char kunnen omzetten', vind ik geen goede werkwijze.