[MySQL] Is dit een beetje verdraagelijk?

[Slagroom]

Ik heb deze tabel, deze tabel alleen... is het verstandig om hier 650.000 adressen in te stoppen en die te publiceren op een website?

code:

CREATE TABLE bedrijven (
  id int(11) NOT NULL auto_increment,
  naam varchar(250) NOT NULL default '',
  adres varchar(250) NOT NULL default '',
  postcode varchar(250) NOT NULL default '',
  woonplaats varchar(250) NOT NULL default '',
  provincie varchar(250) NOT NULL default '',
  telefoon varchar(250) NOT NULL default '',
  fax varchar(250) NOT NULL default '',
  website varchar(250) NOT NULL default '',
  branche varchar(250) NOT NULL default '',
  PRIMARY KEY  (id),
  UNIQUE KEY id (id)
)

Of is het verstandig om er 2 tabellen bij te maken... eentje voor branches en de ander voor provincies ivm het kunnen veranderen van een branchenaam of een provincie naam... (Nu kan dit ook gewoon met update, maar dan moet je ineens 650.000 records bijlangs)

Als ik er 1 of 2 tabellen bij moet maken... dan moet ik 'branche' bijv. koppelen aan 'id' in de tabel 'branches' hoe krijg ik dit voor elkaar? Met inner joins is het niet?

[Verwijderd]

Het ligt er een beetje aan wat je uiteindelijk met de dB wil gaan doen, als je gaat zoeken in een dB van 650000 records is het iets makkelijker om het te verdelen, maar veel maakt het niet uit.

[Verwijderd]

Ik zou branches in een aparte tabel stoppen (en koppelen met een id) en die idd met LEFT JOINs koppelen aan 'bedrijven'.

[dusty]

Het hangt helemaal zoals tuin al zei van je doelstelling af, wat je precies met de data wilt gaan doen.

[Slagroom]

Het is de bedoeling dat het te benaderen is via het internet mbv een script... php of perl één van de 2 (ik denk dat het php wordt) zodat mensen kunnen zoeken op naam, provincie, branche en woonplaats. (Adressen bestand is het trouwens)

[ACM]

Ik snap niet waarom je PER record 250 karakters wilt spenderen aan een provincie naam, daar zijn er tenslotte (in nederland, maar je hebt toch geen andere velden voor land) maar 12 van...
Kan je beter OF met een (2letterige) afkorting opslaan, OF 'gewoon' met een id (laatste kent mijn voorkeur).

Woonplaats zou je hetzelfde mee kunnen doen, maar is al iets minder onhandig (behalve dat het op integers zoeken, dmv id's, veeeeeel sneller gaat dan teksten vergelijken).

En voor branche geldt inderdaad hetzelfde.

Ow nog iets:
PRIMARY KEY (id),
UNIQUE KEY id (id)

Dat is nogal dubbelop... Primary key, is altijd een unique key (een aantal DB's zetten het zelfs om naar een unique key).

[Verwijderd]

/me is het nu met ACM eens, geen verdere uitleg nodig

[dusty]

Op donderdag 24 januari 2002 09:17 schreef ACM het volgende:
Woonplaats zou je hetzelfde mee kunnen doen, maar is al iets minder onhandig (behalve dat het op integers zoeken, dmv id's, veeeeeel sneller gaat dan teksten vergelijken).

En helemaal als het 650.000 records zijn natuurlijk

[bartvb]

Die branches _moeten_ bijna in een aparte tabel als je het ook maar een klein beetje fatsoenlijk wil doen

Verder zou ik postcode+huisnummer (als je dat los kan krijgen) gebruiken ivp 4 vleden voor het adres. Gebruik een postcode tabel en haal daar je adres gegevens uit, kan je meteen kijken of het adres/postcode klopt.

Hmm, on second though op die manier heb je wel een probleem met bedrijven met een postbus, maar die kunnen toch al niet echt fatsoenlijk in deze tabel

Weet verder niet hoe je je gegevens aangeleverd krijgt maar het is echt veel handiger om je naam te splitsen (voor, tussen, achter) zelfde voor je adres (straat, nummer).

[Slagroom]

Op donderdag 24 januari 2002 10:05 schreef bartvb het volgende:
Die branches _moeten_ bijna in een aparte tabel als je het ook maar een klein beetje fatsoenlijk wil doen

Verder zou ik postcode+huisnummer (als je dat los kan krijgen) gebruiken ivp 4 vleden voor het adres. Gebruik een postcode tabel en haal daar je adres gegevens uit, kan je meteen kijken of het adres/postcode klopt.

Hmm, on second though op die manier heb je wel een probleem met bedrijven met een postbus, maar die kunnen toch al niet echt fatsoenlijk in deze tabel

Weet verder niet hoe je je gegevens aangeleverd krijgt maar het is echt veel handiger om je naam te splitsen (voor, tussen, achter) zelfde voor je adres (straat, nummer).

Ik heb gezocht naar een postcode tabel... not found...

Maareuh... moek nou met tabellen (voor elke branche één) gaan werken of met braches en id's?

[Martijn02]

Neeee, niet voor iedere branche een tabel aanmaken, bah!

code:

CREATE TABLE bedrijven (
  id int(11) NOT NULL auto_increment,
  naam varchar(250) NOT NULL default '',
  adres varchar(250) NOT NULL default '',
  postcode char(7) NOT NULL default '',
  woonplaats varchar(250) NOT NULL default '',
  provincieID int(11) NOT NULL default '1',
  telefoon char(15) NOT NULL default '',
  fax char(15) NOT NULL default '',
  website varchar(250) NOT NULL default '',
  brancheID int(11) NOT NULL default '1',
  PRIMARY KEY  (id),
  UNIQUE KEY id (id)
)

CREATE TABLE branche (
  ID int(11) NOT NULL auto_increment,
  naam char(255) NOT NULL default '',
  PRIMARY KEY  (id)
)

CREATE TABLE provincie (
  ID int(11) NOT NULL auto_increment,
  naam char(25) NOT NULL default '',
  PRIMARY KEY  (id)
)

Ok, veranderingen die ik heb gedaan... Ik heb 2 aparte tabelletjes branche en provincie gemaakt, die door 2 foreign keys gekoppeld moeten worden aan bedrijf.

Verder heb ik wat varchars veranderd door chars, hierdoor sla je af en toe wat spaties op, maar dan worden je records even groot, hierdoor hoeft de database bij het zoeken niet naar het begin van het volgende record te zoeken, maar kan hij de iterator gewoon een record verder zetten, zeker voor provincie en branche is dat prettig. De groottes van de velden heb ik ook wat aangepast, volgens mij zijn er geen provincies met een naam die langer is dan 25 chars (als je een na-telt kan hij vast nog wel korter. Ook voor de postcode lijk een varchar van 255 een beetje overkill, een chat van 7 is voldoende (6 zou ook nog kunnen, maar als je de spatie laat staan staat het beter)

Volgens mij ben je zo aardig op weg...

/edit:
Nou kan je op de website mooi selectievakjes maken waar je provincie en branche in kan selecteren, zodat je de ID's er al van weet, dat scheelt weer query's

even een query om je op weg te helpen

$brancheID, $provincieID, $naam worden door een formuliertje aangeleverd als variablen, mochten ze NULL of 0
zijn dan kan je de regels waar ze in voorkomen weglaten uit de query

code:

SELECT *
FROM bedrijven
LEFT JOIN branche ON bedrijven.brancheID = branche.ID 
LEFT JOIN provincie ON bedrijven.provincieID = provincie.ID
WHERE bedrijven.brancheID = $brancheID
  AND bedrijven.provincieID = $provincieID
  AND bedrijven.naam LIKE "%$naam%"

[Slagroom]

Thank you! Maarreuh... hoe maak ik die joins?

Sorry dat ik zoveel vraag maareuh... met die tabellen is niet zo moeilijk... maar met joins heb ik nooit gewerkt, ik doe het altijd de hard way mbv van php en dan weer zo en dan weer zo... maar ja... toen ik van die joins hoorde... Das ja beter...

edit:

Oeps sorry... te laat

[Bpje]

Het is even de vraag wat je er mee wilt gaan doen je zegt een website maar wil je mensen laten zoeken op VB: naam, brache, woonplaats of provincie.

Als dat zo is zou ik ze zeker opsplitsen. Dan zijn de sugesties die hier boven staan zeker goed.

Verder zou ik die varchars veranderen in het type text zorgt voor minder overhead in je db.

Dus samenvatten
CREATE TABLE BEDRIJFNAW
id int(11) NOT NULL auto_increment,
naam text NOT NULL default '',
adres text NOT NULL default '',
postcode varchar(7) NOT NULL default '',
telefoon varchar(14) NOT NULL default '',
fax varchar(14) NOT NULL default '',
website text NOT NULL default ''
PRIMARY KEY (id),
UNIQUE KEY id (id)
)

CREATE TABLE BEDRIJFBRANCE (
id int(11) NOT NULL auto_increment,
branche text NOT NULL default '',
PRIMARY KEY (id),
UNIQUE KEY id (id)
)

CREATE TABLE BEDRIJFLOKATIE (
id int(11) NOT NULL auto_increment,
woonplaats text NOT NULL default '',
provincie smallint(2) NOT NULL default '',
PRIMARY KEY (id),
UNIQUE KEY id (id)
)

provincie smallint(2) NOT NULL default '',
VB
1= friesland
2= enz

dat kun je verwerken in je source of in de db.

misschien is het ook een idee om brance een vaste selectie van te maken zo krijg je minder last dat je 650.000 :)verschilende krijgt.

[Bpje]

[b]Op donderdag 24 januari 2002 11:05 schreef
Ok, veranderingen die ik heb gedaan... Ik heb 2 aparte tabelletjes branche en provincie gemaakt, die door 2 foreign keys gekoppeld moeten worden aan bedrijf.

sorry maar foreign keys worden volgens mij nog niet ondersteund, ze zijn er wel mee bezig maar dat is nog in alpha.

[Martijn02]

Op donderdag 24 januari 2002 11:45 schreef Bpje het volgende:
Verder zou ik die varchars veranderen in het type text zorgt voor minder overhead in je db.

Dat mag je me even uitleggen dan, want ik ben altijd van mening geweest dat een text veel meer overhead verzorgt, en daarbij ook dat je je variabelen altijd zo klein mogelijk moet opslaan. In een text kunnen veel meer dan 255 chars, en volgens zijn texts ook een stuk trager dan varchars

[Martijn02]

Leuk zo, met z'n 2en quoten...

Op donderdag 24 januari 2002 11:47 schreef Bpje het volgende:
[..]
sorry maar foreign keys worden volgens mij nog niet ondersteund, ze zijn er wel mee bezig maar dat is nog in alpha.

Forein keys hoeven niet door de database ondersteund te worden om ze te gebruiken. Je moet er nu alleen zelf op letten dat je geen branche record weggooit als er nog bedrijven zijn met dat brancheID, voor de rest gebruik je ze zelf toch ook in het bovenstaande voorbeeld?

[Slagroom]

Maar hoef ik bij het creeren van de tabellen geen joins aan te geven? Tussen bijvoorbeeld bedrijven.brancheID en branches.ID

[Martijn02]

Nee hoor, je moet alleen zelf onthouden dat een provincieID verwijst naar een record in de tabel provincie. En als je dat een beetje handig doet met de naamgeving is dat heel makkelijk..

[Bpje]

Op donderdag 24 januari 2002 11:54 schreef Martijn02 het volgende:

Forein keys hoeven niet door de database ondersteund te worden om ze te gebruiken. Je moet er nu alleen zelf op letten dat je geen branche record weggooit als er nog bedrijven zijn met dat brancheID, voor de rest gebruik je ze zelf toch ook in het bovenstaande voorbeeld?

ja dat klopt maar foriegn zijn meer het alleen noemen van een id, een foriegn key is een directe verwijzing naar een andere tabel op database niveau.
dus als je een foriegn key gebruik VB:

code:

2 tabelen 
fiets
  id 
  kleur
  wielen <- foriegn key naar wielen_id
 
wielen
  wielen_id 
  soort
  ....

fiets
1 groen 1
2 blauw 2
 
wielen
1 spaken 
3 geen

nu verwijst fiets 2 naar een de tabel wielen en veld wielen_id maar 2 bestaat niet dus kan fiets 2 ook niet bestaan. Vindt het moeilijk om uitteleggen.

Waarom text ipv varchar text is dynamisch dus neemt de benodigd grootte in plus een paar bytes dus weinig overhead.

ik hoop dat het duidelijk is.

[Slagroom]

Hé, cool, makkelijker dan ik dacht...

Maar nu heb ik bijvoorbeeld 20 branches en de bedrijven die daar bij horen moeten per branche in een andere <html> tabel komen (Beetje het startpagina.nl gevoel) Hoe komt zo'n query er dan uit te zien?

[dusty]

Op donderdag 24 januari 2002 12:38 schreef Bpje het volgende:
[..]Waarom text ipv varchar text is dynamisch dus neemt de benodigd grootte in plus een paar bytes dus weinig overhead.[..]

Mag jij aan mij gaan uitleggen wat het verschil is tussen CHAR en VARCHAR ( en VARCHAR2 )

[Bpje]

Op donderdag 24 januari 2002 12:38 schreef Monstar.nl het volgende:
Hé, cool, makkelijker dan ik dacht...

Maar nu heb ik bijvoorbeeld 20 branches en de bedrijven die daar bij horen moeten per branche in een andere <html> tabel komen (Beetje het startpagina.nl gevoel) Hoe komt zo'n query er dan uit te zien?

kun je denk ik het beste in 2 querys doen

PHP:

<?
$SQLselect = 'SELECT distinct(branche) '.
             'FROM bedrijvenbranche';
$result = mysql_query($SQLselect);
while ($row = mysql_fetch_array($result))
{
    $SQLselect2 = 'SELECT b.id,n.naam,... '.
        'FROM bedrijfbranche b, bedrijfnaw n '.
        'WHERE b.id = n.id AND b.branche='.$row['branche'];
    $result2 = mysql_query($SQLselect2);
    while ($row2 = mysql_fetch_array($result2))
    {
        print('id ='.$row['id'].'<br />');
        print('naam ='.$row['naam'].'<br />');
    }
}
?>

[Bpje]

Hier is een uitleg tussen char en varchar.

[Grum]

postcode is maar 6 chars (gewoon whitespace eruit hakken) telefoon/fax is in princiepe maar 9 chars (0 weglaten en de whitespaces ook) voordeel hiervan is dat het ook in een int kan (omdat er GEENEEN nummer begint met dubbel 0)

p0m p0m p0m

[Bpje]

Op donderdag 24 januari 2002 13:11 schreef Grum_ het volgende:
postcode is maar 6 chars (gewoon whitespace eruit hakken) telefoon/fax is in princiepe maar 9 chars (0 weglaten en de whitespaces ook) voordeel hiervan is dat het ook in een int kan (omdat er GEENEEN nummer begint met dubbel 0)

p0m p0m p0m

okay is een idee nu heb ik mijn bedrijf in nederland en woon in duitsland en wil ik dat mensen mij thuis bellen.

Dan kun je beter wel meer dan 10 geven ( iets zonder uitzonderingen bestaat bijna niet) "gelukkig maar, want als er geen uitzonderingen zijn, was dat al een uitzonderlijk geweest"

[Martijn02]

Op donderdag 24 januari 2002 12:38 schreef Bpje het volgende:
ja dat klopt maar foriegn zijn meer het alleen noemen van een id, een foriegn key is een directe verwijzing naar een andere tabel op database niveau.
dus als je een foriegn key gebruik VB:

code:

2 tabelen 
fiets
  id 
  kleur
  wielen <- foriegn key naar wielen_id
 
wielen
  wielen_id 
  soort
  ....

fiets
1 groen 1
2 blauw 2
 
wielen
1 spaken 
3 geen

nu verwijst fiets 2 naar een de tabel wielen en veld wielen_id maar 2 bestaat niet dus kan fiets 2 ook niet bestaan. Vindt het moeilijk om uitteleggen.

Dus je moet zelf controleren of een entry in de tabel wielen ook bestaat voordat je hem linkt in de tabel fiets. Dat is echt het enige wat een database met ondersteuning voor foreign key's meer doet. En als je een record uit de tabel wielen wil verwijderen moet je eerst zeker weten dat er geen fietsen meer naar linken.

Ik bedoel met foreign keys de constructie dat je vanuit de ene tabel verwijst naar een key in een andere tabel. da's alles, en zoiets noem je een foreign key, en of de database daar nou wel of geen ondersteunende controle's voor wil uitvoeren maakt niks uit...

Waarom text ipv varchar text is dynamisch dus neemt de benodigd grootte in plus een paar bytes dus weinig overhead.

ik hoop dat het duidelijk is.

Nee, is niet duidelijk, je informatie klopt namelijk niet.

Een char is vast, een char(4) zal altijd 4 bytes groot zijn.
Een varchar(255) is variabel, zal altijd length(text)+1 groot zijn, met een maximum van 256 (vandaar dat hij maar max 255 groot mag zijn)

Een text is hetzelfde systeem, echter dan groter, daarnaast worden text variablen appart opgeslagen, dus het ophalen van deze kolommen duurt veel langer, omdat er eigenlijk 2 query's nodig zijn om een text op te halen

Dat lijkt me niet echt bevorderlijk voor de snelheid van het systeem, dus als het in een varchar of char past stop je je info in een varchar of char

In de meeste gevallen is een char sneller omdat hij een vaste grootte heeft, een varchar daartegenover is weer zuiniger in schijfruimte. Ikzelf probeer in de meeste gevallen een char te gebruiken, behalve als de lengthe van de toekomstige inhouden erg ver uit elkaar ligt.

[Martijn02]

Op donderdag 24 januari 2002 12:56 schreef Bpje het volgende:

kun je denk ik het beste in 2 querys doen

PHP:

<?
$SQLselect = 'SELECT distinct(branche) '.
             'FROM bedrijvenbranche';
$result = mysql_query($SQLselect);
while ($row = mysql_fetch_array($result))
{
    $SQLselect2 = 'SELECT b.id,n.naam,... '.
        'FROM bedrijfbranche b, bedrijfnaw n '.
        'WHERE b.id = n.id AND b.branche='.$row['branche'];
    $result2 = mysql_query($SQLselect2);
    while ($row2 = mysql_fetch_array($result2))
    {
        print('id ='.$row['id'].'<br />');
        print('naam ='.$row['naam'].'<br />');
    }
}
?>

Dat zijn geen 2 query's maar (aantalbranches+1) queries

PHP:

<?
$SQLselect = 'SELECT distinct(branche)
?>

is niet helemaal lekker... Ten eerste is dit geen sql syntax

code:

$SQLselect = 'SELECT DISTINCT branche

is beter. En daarnaast, waarom zou je in hemelsnaam een distinct gebruiken hier? Het is juist de bedoeling dat je elke branche maar een keer opslaat, anders heb je precies hetzelfde effect als wanneer je de branchenaam direct bij het bedrijf opslaat.

[Martijn02]

Op donderdag 24 januari 2002 13:11 schreef Grum_ het volgende:
postcode is maar 6 chars (gewoon whitespace eruit hakken) telefoon/fax is in princiepe maar 9 chars (0 weglaten en de whitespaces ook) voordeel hiervan is dat het ook in een int kan (omdat er GEENEEN nummer begint met dubbel 0)

p0m p0m p0m

Het is erg slim gedacht, maar mischien een beetje over the top. Die spatie in postcode zou ik gewoon lekker laten staan, het er uit halen, en er weer in stoppen is meer werk dan het inlezen van die ene byte. De grootte van de tabel wordt dan 650.000 bytes (600k) groter. Op de grootte van de hele database is dat maar zo'n klein percentage dat dat IMHO zinloos werk is.

Het opslaan van telefoonnummers in een INT is ook origioneel, heb ik nog nooit gezien, hoewel dit wel een hoop ruimte spaart (+-15 bytes tegenover 4 bytes) beperkt dit je wel heel erg in je mogelijkheiden, stel je wil een doorkiesnummer opslaan ofzo, niet alle nr's zijn 9 chars lang. Of idd in het buitenland, of mischien wil je wel een naambel-nummer opslaan, weet ik veel: 0900-TWEAKERS, ik verzin maar wat...

[Bpje]

Op donderdag 24 januari 2002 13:53 schreef Martijn02 het volgende:

Nee, is niet duidelijk, je informatie klopt namelijk niet.

Een char is vast, een char(4) zal altijd 4 bytes groot zijn.
Een varchar(255) is variabel, zal altijd length(text)+1 groot zijn, met een maximum van 256 (vandaar dat hij maar max 255 groot mag zijn)

Een text is hetzelfde systeem, echter dan groter, daarnaast worden text variablen appart opgeslagen, dus het ophalen van deze kolommen duurt veel langer, omdat er eigenlijk 2 query's nodig zijn om een text op te halen

Dat lijkt me niet echt bevorderlijk voor de snelheid van het systeem, dus als het in een varchar of char past stop je je info in een varchar of char

In de meeste gevallen is een char sneller omdat hij een vaste grootte heeft, een varchar daartegenover is weer zuiniger in schijfruimte. Ikzelf probeer in de meeste gevallen een char te gebruiken, behalve als de lengthe van de toekomstige inhouden erg ver uit elkaar ligt.

Ik geef je gelijk maar (ja altijd een maar) heb net ook ff opgezocht een varchar is het zelfde princiepe als text maar text is niet beperkt in grootte zodat je meer vrijheid hebt wat je invult.

die 2 querys waar je het over hebt die worden wel uit gevoert maar wel op een manier waar je systeem niet zo veel van merkt.

Maar volgens mij gaat het al niet meer over de db die hij wou bouwen.

[Martijn02]

Op donderdag 24 januari 2002 14:18 schreef Bpje het volgende:

[..]

Ik geef je gelijk

pfff, eindelijk gerechtigeid... begon al aan mezelf te twijfelen

maar (ja altijd een maar) heb net ook ff opgezocht een varchar is het zelfde princiepe als text maar text is niet beperkt in grootte zodat je meer vrijheid hebt wat je invult.

Waar heb je dat gevonden? en over welke database heb je het dan? want dan ben ik inderdaad mistaken. IMHO werd (en wordt) een varchar namelijk gewoon in het record zelf opgeslagen. (daardoor krijg je een variabele recordgrootte wat niet snel werkt) Als ze het zo opgelost hebben is het inderdaad wel slim, alleen ben ik bang dat het niet zo is, anders zouden het verschil tussen varchar en text inderdaad miniem zijn

die 2 querys waar je het over hebt die worden wel uit gevoert maar wel op een manier waar je systeem niet zo veel van merkt.

Helemaal waar. het is eigenlijk allemaal gemierenn**k

Maar volgens mij gaat het al niet meer over de db die hij wou bouwen.

inderdaad, we zijn zwaar offtopic bezig. Des-al-niet-te-min is het wel interresant...

[Bpje]

Op donderdag 24 januari 2002 14:00 schreef Martijn02 het volgende:

[..]

Dat zijn geen 2 query's maar (aantalbranches+1) queries

PHP:

<?
$SQLselect = 'SELECT distinct(branche)
?>

is niet helemaal lekker... Ten eerste is dit geen sql syntax

code:

$SQLselect = 'SELECT DISTINCT branche

is beter. En daarnaast, waarom zou je in hemelsnaam een distinct gebruiken hier? Het is juist de bedoeling dat je elke branche maar een keer opslaat, anders heb je precies hetzelfde effect als wanneer je de branchenaam direct bij het bedrijf opslaat.

Als je dat doet is het ook geen probleem maar als je kijt hoe ik de db heb opgezegt zie je dat dat niet het geval is.
Dus de DISTINCT is wel nodig.

Nee je hebt dan niet het zelfde effect omdat er je niet in de zelfde db aan het lesen bent als iedereen dus je houdt de selects appart en als het wel zou zijn dan klopt er echt niets van die structuur. Want hoe koppel ik dan een bedrijf aan een branche?? of een plaats???

en het zijn wel twee querys selecteerd eerst de mogelijk heden en daarna de bedrijven die aan voldoen erbij horen.

als MYSQL sub selects zou ondersteunen dan zou je IN kunnen gebruiken maar helaas zover is het nog niet.

leg mij maar eens uit wat dit betekend??
"Dat zijn geen 2 query's maar (aantalbranches+1) queries"

Die haakjes waren een gedachte foutje zat te denken aan SUM en COUNT.

[Bpje]

Hier

en ja het is erg intresant.

www.mysql.com

[Martijn02]

Gaan we weer....

Op donderdag 24 januari 2002 14:35 schreef Bpje het volgende:

[..]

Als je dat doet is het ook geen probleem maar als je kijt hoe ik de db heb opgezegt zie je dat dat niet het geval is.
Dus de DISTINCT is wel nodig.

Jamaar waarom haal je ze dan nog uit elkaar? laat hem er dan gewoon in in staan

Nee je hebt dan niet het zelfde effect omdat er je niet in de zelfde db aan het lesen bent als iedereen dus je houdt de selects appart en als het wel zou zijn dan klopt er echt niets van die structuur. Want hoe koppel ik dan een bedrijf aan een branche?? of een plaats???

Met een join?

en het zijn wel twee querys selecteerd eerst de mogelijk heden en daarna de bedrijven die aan voldoen erbij horen.

Ja maar die laatste query wordt voor iedere mogelijkheid opnieuw uitgevoerd = meer query's

als MYSQL sub selects zou ondersteunen dan zou je IN kunnen gebruiken maar helaas zover is het nog niet.

in kan je gewoon gebruiken, is iets anders dan een subselect, maar met een join is dat niet nodig

leg mij maar eens uit wat dit betekend??
"Dat zijn geen 2 query's maar (aantalbranches+1) queries"

Die haakjes waren een gedachte foutje zat te denken aan SUM en COUNT.

dat is alleen maar om aan te geven hoeveel queries je doet

Ik geloof niet dat ik het je duidelijk kan maken, ik loop steeds te beweren dat jij het niet goed doet, wan IMHO ook zo is, en jij zegt van wel, we praten langs elkaar heen.

Ik geef het hierbij op, mischien dat iemand anders Bpje nog kan overtuigen, mischien kan je er nog een boek bij pakken ofzo, mocht je ergens een goed boek hebben dat ergens de voordelen jouw methode beschrijft houd ik me warm aanbevolen, doe me eens een mailtje ofzo.

Mocht je meer over mijn methode willen lezen, pak een willekeurig database/sql boek...

Op donderdag 24 januari 2002 14:39 schreef Bpje het volgende:
Hier

en ja het is erg intresant.

www.mysql.com

Is onzin, daar staat helemaal niet dat varchars buiten de tabel worden opgeslagen, althans... ik kan het niet vinden.

[Bpje]

idd daar gaan we weer sorry ik bedoel het echt goed maar zal van vooraf aan beginnen,

iemand komt op zijn site, leuk bedrijven per branche (list boxe wordt gevult uit de DB) Ja query SELECT DISTINCT bla bla bla hij selecteerd een branche SELECT id FROM .. WHERE branch="" goed dan haalt hij de id's op en die kun je weer invoeren in een query (kan ook met een join natuurlijk)

Hij wil de mensen tonen op een "startpagina" manier per branche dus je moet eerst weten welke braches er zijn.
en dan welke bedrijven.

Op donderdag 24 januari 2002 14:51 schreef Martijn02 het volgende:
Gaan we weer....
[..]

Jamaar waarom haal je ze dan nog uit elkaar? laat hem er dan gewoon in in staan
[..]

Met een join?
[..]

Ja maar die laatste query wordt voor iedere mogelijkheid opnieuw uitgevoerd = meer query's

Hoe wil je het dan doen? dan moet je als nog een key opnemen in de NAW tabel. Een join is ook een goeie oplossing alleen een grotere db.

[..]

in kan je gewoon gebruiken, is iets anders dan een subselect, maar met een join is dat niet nodig

Je weet wat er gebeurt met een join dan vermenigvuldig je de tabelen dus als nog log. Je doet moeite om ze uit elkaar te halen en dan doe je een join.

SELECT * FROM tabel WHERE id IN (SELECT ID FROM tabel2)

dat is een sub select.

[..]

dat is alleen maar om aan te geven hoeveel queries je doet

Ik geloof niet dat ik het je duidelijk kan maken, ik loop steeds te beweren dat jij het niet goed doet, wan IMHO ook zo is, en jij zegt van wel, we praten langs elkaar heen.

Ik geef het hierbij op, mischien dat iemand anders Bpje nog kan overtuigen, mischien kan je er nog een boek bij pakken ofzo, mocht je ergens een goed boek hebben dat ergens de voordelen jouw methode beschrijft houd ik me warm aanbevolen, doe me eens een mailtje ofzo.

Mocht je meer over mijn methode willen lezen, pak een willekeurig database/sql boek...

Jammer dat je het opgeeft en een lekker steek in mijn rug geeft. Wil het er graag nog een keer over hebben dus mail me maar.!!

sorry ik heb redelijke ervaring met db's en denk dat we al bij een goeie oplossing hebben. Maar je bent mij wat te door drijvend met je reacties.

[Femme]

In de <A href='http://www.innodb.com/ibman.html#InnoDB_tuning' target=_blank>InnoDB manual</a> wordt het gebruik van varchars juist geadviseerd omdat het disk I/O en ruimte in de buffer bespaard. MyISAM zet char kolommen bij het maken van een table automatisch om naar varchar als het denkt dat varchars beter zijn. Bij kolommen met een sterk variërende lengte zoals namen zou ik gewoon varchars gebruiken.

[Verwijderd]

Op donderdag 24 januari 2002 15:40 schreef Femme het volgende:
In de <A href='http://www.innodb.com/ibman.html#InnoDB_tuning' target=_blank>InnoDB manual</a> wordt het gebruik van varchars juist geadviseerd omdat het disk I/O en ruimte in de buffer bespaard. MyISAM zet char kolommen bij het maken van een table automatisch om naar varchar als het denkt dat varchars beter zijn. Bij kolommen met een sterk variërende lengte zoals namen zou ik gewoon varchars gebruiken.

Is VARCHAR niet een wat scheve naam? Zo VARiabel is de lengte van die CHARs toch helemaal niet? (In MySQL)

[Bpje]

Femme ik ben met je eens (dat had ik ook al gezegt) maar het ging niet meer om een varchar hier of een char daar maar wat nou handiger was joinen ja of nee.

[dusty]

Op donderdag 24 januari 2002 14:18 schreef Bpje het volgende:
[..]
Ik geef je gelijk maar (ja altijd een maar) heb net ook ff opgezocht een varchar is het zelfde princiepe als text maar text is niet beperkt in grootte zodat je meer vrijheid hebt wat je invult.
[..]

Goh, zou dat komen omdat ze misschien op verschillende manieren worden opgeslagen binnen een normale database?

Zou dat wel eens invloed kunnen hebben op het geheel bij bepaalde queries zoals bij het zoeken en het gebruik van like statements?

Femme ik ben met je eens (dat had ik ook al gezegt) maar het ging niet meer om een varchar hier of een char daar maar wat nou handiger was joinen ja of nee.

Voor het joinen maakt het char / varchar / text verhaal absoluut niet uit, Wat het wel uitmaakt is snelheid en dat telt vooral aan als je de like statement gaat gebruiken.

Ook was jouw initiale statement het volgende:

[..]Waarom text ipv varchar text is dynamisch dus neemt de benodigd grootte in plus een paar bytes dus weinig overhead.[..]

Nu geef je zelf dus al toe dat varchar ook dynamisch is en ook de benodigde grootte in neemt (plus een paar bytes), dus moet je toegeven dat je statement eerder fout was ( en dus de reden waarom er text gebruikt moest worden fout was.)

Bovendien kijk je hier dan alleen maar naar de ruimte die hij direct in de table gebruikt, Dan ga je nog niet kijken welke invloeden deze hebben indien je dat kolom gaat indexeren.

[Slagroom]

Jeetje... ik gebruik text alleen bij teksten en varchar bij... ja... sterk varierende karakter lengtes... maar ja... ik houd me bek wel

Op donderdag 24 januari 2002 12:56 schreef Bpje het volgende:

[..]

kun je denk ik het beste in 2 querys doen

PHP:

<?
$SQLselect = 'SELECT distinct(branche) '.
             'FROM bedrijvenbranche';
$result = mysql_query($SQLselect);
while ($row = mysql_fetch_array($result))
{
    $SQLselect2 = 'SELECT b.id,n.naam,... '.
        'FROM bedrijfbranche b, bedrijfnaw n '.
        'WHERE b.id = n.id AND b.branche='.$row['branche'];
    $result2 = mysql_query($SQLselect2);
    while ($row2 = mysql_fetch_array($result2))
    {
        print('id ='.$row['id'].'<br />');
        print('naam ='.$row['naam'].'<br />');
    }
}
?>

Ook als ik 3 tabellen gebruik?

kan dit trouwens:

PHP:

<?
$SQLselect = 'SELECT id FROM bedrijvenbranche';
$result = mysql_query($SQLselect);
while ($row = mysql_fetch_array($result))
{
    $SQLselect2 = 'SELECT id,naam '.
        'FROM bedrijven'.
        'WHERE b.brancheID='.$row['id'];
    $result2 = mysql_query($SQLselect2);
    while ($row2 = mysql_fetch_array($result2))
    {
        print('id ='.$row['id'].'<br />');
        print('naam ='.$row['naam'].'<br />');
    }
}
?>

niet? Zo niet waarom?

PS: Ik wordt hier echt geholpen! Vet cool!

[Slagroom]

niet goed dus?

[Slagroom]

?

[Bpje]

Op donderdag 24 januari 2002 20:14 schreef Monstar.nl het volgende:
kan dit trouwens:

PHP:

<?
$SQLselect = 'SELECT id FROM bedrijvenbranche';
$result = mysql_query($SQLselect);
while ($row = mysql_fetch_array($result))
{
    $SQLselect2 = 'SELECT id,naam '.
        'FROM bedrijven'.
        'WHERE b.brancheID='.$row['id'];
    $result2 = mysql_query($SQLselect2);
    while ($row2 = mysql_fetch_array($result2))
    {
        print('id ='.$row['id'].'<br />');
        print('naam ='.$row['naam'].'<br />');
    }
}
?>

niet? Zo niet waarom?

Greaag gedaan hoor,
Maar het is een beetje zinloos stukje code want je selecteerd eerst alle id's en dan ga je met alle id's kijken of er 1 bestaat met die id. Dan krijg je dus alle bedrijven.

als je hem aanpast

PHP:

<?
$SQLselect = 'SELECT id FROM bedrijvenbranche WHERE brance="'.$eenbranche'"';
$result = mysql_query($SQLselect);
while ($row = mysql_fetch_array($result))
{
    $SQLselect2 = 'SELECT id,naam '.
        'FROM bedrijven'.
        'WHERE b.brancheID='.$row['id'];
    $result2 = mysql_query($SQLselect2);
    while ($row2 = mysql_fetch_array($result2))
    {
        print('id ='.$row['id'].'<br />');
        print('naam ='.$row['naam'].'<br />');
    }
}
?>

(where bij het eerste gedeelte)
zou doen dan zou je alle bedrijven krijgen in 1 branche.

zelf had ik een functie gemaakt die een array terug geeft

function GeefBedrijf(id)
{
#post: een id van een bedrijf
#return: een associative array met daar in NAW enz
}

[Slagroom]

Zelf zou ik het zo doen:

PHP:

<?
mysql_connect();
mysql_select_db('bedrijven');

$sql = 'SELECT id,naam FROM branches';
$res = mysql_query($sql) or die(mysql_error());

while($row=mysql_fetch_object($res))
 $idb[$id] = $row->naam;
 
foreach($idb AS $id => $branche) {
 ?>
 <table>
   <tr>
    <td>
     <? echo $branche ?>
    </td>
   </tr>
   <tr>
    <td>
 <?
 $sql = "SELECT id,naam FROM bedrijven WHERE brancheID = $id";
 $res = mysql_query($sql) or die(mysql_error());
 while($row=mysql_fetch_object($res))
  echo $row->id." -> ".$row->naam;
 ?>
    </td>
   </tr>
  </table>
 <?
}
?>

Maar het moet toch makkelijker kunnen?

Want nu voer je elke keer bijvoorbeeld bij 100 branches 100+1 query's uit... is dat niet een beetje overdreven? Kan dit niet in minder?

[Bpje]

waarom doe je geen join en dan GROUP BY branche of zelfs ORDER by branche??
Dan loop je door je resultaten en zodra een andere branche komt dan pleur je er een stuk je html tussen.

[Slagroom]

Op vrijdag 25 januari 2002 11:51 schreef Bpje het volgende:
waarom doe je geen join en dan GROUP BY branche of zelfs ORDER by branche??
Dan loop je door je resultaten en zodra een andere branche komt dan pleur je er een stuk je html tussen.

Kan ook, dan heb ik maar één tabel nodig... en één query... das ook weer handig... maar in het begin zeiden ze dat ik de branches beter in een andere tabel kon zetten... (Tenminste dat maakte ik er uit)

[Bpje]

ja klopt daar zei ik ook een join.

Maar goed met 1 tabel maakt het niet uit doe maar wat

Nee hoor, Je moet kijken wat voor jou het makelijkste is en het minste werk kost ik denk eigenlijk het opsplitzen een hoop geneuk is om niets en dat het uit eindelijk wel mee valt.

dus 1 tabel

verder nog vragen kun je me altijd mailen (geen internet in het weekend )

[Slagroom]

Op vrijdag 25 januari 2002 11:51 schreef Bpje het volgende:
waarom doe je geen join en dan GROUP BY branche of zelfs ORDER by branche??
Dan loop je door je resultaten en zodra een andere branche komt dan pleur je er een stuk je html tussen.

Ow nee... kan niet... ik moet ze in tweeën delen... dus zo

code:

+----------+----------+
|+--------+|+--------+|
||A  |||E    ||
|+--------+|+--------+|
||B  |||F    ||
|+--------+|+--------+|
||C  |||G    ||
|+--------+||--------+|
||D  ||     |
|+--------+|        |
+----------+----------+

Trouwens dit moet de uitvoer worden... in html...


Dus ik dacht alle branches tellen en dan met limit door 2 delen... hmmmm... kun je het met 2 query's doen... is het niet? Of met één?

[Bpje]

Dan het nog steeds alleen dan moet je wat voorbereidingen doen.
1.
zoek uit hoeveen branche er zijn en dat stop je ergens in
($aantalbranche)

2.
<table>
<tr>
<td>

3.
query die ORDER by branche heeft

4.
je print de bedrijf per brance in zijn eigen tabel.

5.
je kijkt hoe vaak je wisselt met branche en als je $aantalbranche / 2 wisselin komt den voeg je een </td><td> toe en ga je vrolijk verder.

code:

+----------+----------+
|+--------+|+--------+|
||A  |||E    ||
|+--------+|+--------+|
|+--------+|+--------+|
||B  |||F    ||
|+--------+|+--------+|
|+--------+|+--------+|
||C  |||G    ||
|+--------+|+--------+|
|+--------+|        |
||D  ||     |
|+--------+|        |
+----------+----------+

[Slagroom]

Jeetje, bedankt! Ha, dus als ik het zo doe is het goed? Maar als ik nou bijvoorbeeld branch 'Snordrukkers' wil omzetten naar 'Lapzwanzen' dan doe ik dat met UPDATE bla WHERE bla bla en dan moek een heel tering eind door de database... terwijl ik dat met... ach laat ook maar... zo als jij het zegt doe ik het gewoon! BEDANKT