// Nu de query uitvoeren
?>
Maar waarom zou je met php een tabel aan willen maken? Als het geen installatiescript van een systeem betreft, heb je in de meeste gevallen te maken met een fout datamodel. En dat de tabelnaam variabel kan zijn, doet niets goeds vermoeden.
<?php
$name = "voorbeeld";
$sql = "
CREATE TABLE ".$name." (
id INT,
url VARCHAR(100)
)
";
// uitvoeren van de query, etc. etc.
?>
Maar, waar heb je dit voor nodig? Tabellen maak je 1x aan en daarna nooit meer. Het kan dus hooguit voor een installatie-script worden gebruikt of voor jouw eigen variant op PhpMyAdmin. Alle andere andere toepassingen zijn fout. (beetje zwart-wit, maar toch)
Edit: @Blanche: het moet niet veel gekker worden! We denken echt hetzelfde...
De naam 'http://www.domein.com'; is niet toegestaan en de naam slaat nergens op.
Dit is namelijk data en data staat in records en records staan in tabellen. Hier zou je dus een tabel 'domeinnamen' aanmaken en daarbij dan de naam, het subdomein en de extensie opslaan. Ook het protocol zou je nog kunnen opslaan:
De naam 'http://www.domein.com'; is niet toegestaan en de naam slaat nergens op.
Dit is namelijk data en data staat in records en records staan in tabellen. Hier zou je dus een tabel 'domeinnamen' aanmaken en daarbij dan de naam, het subdomein en de extensie opslaan. Ook het protocol zou je nog kunnen opslaan:
Ik zal eerst maar eens uitleggen waar het on gaat.
Ik probeer advertentiesysteem te bouwen icm een webspider. Deze spider gaat een url crawlen die opgegeven is in $name als bijvoorbeeld http://www.domein.com
De links die de spider ophaalt uit het opgegeven domein moeten geplaatst worden in een tabel (dit heb ik al voor mekaar), maar die tabel moet genoemd zijn naar het domein, in dit geval dus "domeincom"
Deze waarde voor de naam van de tabel moet gemaakt worden door "http://www."; en "." te verwijderen uit de waarde in $name, mijn vraag is dus, hoe doe ik dat?
Nee dus, dat doe je niet. Daarmee zou je een grote blunder begaan en direct alle verbanden met andere stukken data naar de bliksem helpen.
Je denkt toch niet dit hier op phphulp voor de reacties van mij een andere tabel wordt gebruikt dan voor de reacties van jou? Een tabel users en een tabel reacties met daartussen een foreignkey en klaar is kees. Oneindig veel users met oneindig veel reacties en dat in slechts 2 tabelletjes.
Ga normaliseren, dan zul je dit zelf ook inzien.
Edit: En nog even een linkje naar de meest populaire tutorial. Doe er je voordeel mee en gooi je huidige database weg! Ga eerst normaliseren en daarna een nieuwe database opzetten. Vergeet de huidige opzet, die is zo fout als het maar zijn kan.
Nee dus, dat doe je niet. Daarmee zou je een grote blunder begaan en direct alle verbanden met andere stukken data naar de bliksem helpen.
Je denkt toch niet dit hier op phphulp voor de reacties van mij een andere tabel wordt gebruikt dan voor de reacties van jou? Een tabel users en een tabel reacties met daartussen een foreignkey en klaar is kees. Oneindig veel users met oneindig veel reacties en dat in slechts 2 tabelletjes.
Ga normaliseren, dan zul je dit zelf ook inzien.
Edit: En nog even een linkje naar de meest populaire tutorial. Doe er je voordeel mee en gooi je huidige database weg! Ga eerst normaliseren en daarna een nieuwe database opzetten. Vergeet de huidige opzet, die is zo fout als het maar zijn kan.
Ik begrijp dat je er het nut niet van inziet, maar wanneer ik 100 sites zou crawlen met elk 20 pagina's met op elke pagina weer 5 links, dan zit ik al snel aan erg veel records, van verschillende sites, in EEN tabel.
Dat is niet handig om mee te werken, dus kan ik door normalisering van de domeinnaam als tabelnaam (http://www.domein.com --> domeincom = uniek) eenvoudig ook gerichte query's draaien...
Ik heb oevrigens al een eenvoudige oplossing gemaakt, namelijk:
Ik begrijp dat je er het nut niet van inziet, maar wanneer ik 100 sites zou crawlen met elk 20 pagina's met op elke pagina weer 5 links, dan zit ik al snel aan erg veel records, van verschillende sites, in EEN tabel.
Yeah, right.
Even wat gegevens van PostgreSQL:
Limit Value
Maximum Database Size Unlimited
Maximum Table Size 32 TB
Maximum Row Size 1.6 TB
Maximum Field Size 1 GB
Maximum Rows per Table Unlimited
Maximum Columns per Table 250 - 1600 depending on column types
Maximum Indexes per Table Unlimited
En dan bv. het datatype BIGINT:
Name Storage Size Description Range
bigint 8 bytes large-range integer -9223372036854775808 to 9223372036854775807
En voor jouw leesgemak: 9.223.372.036.854.775.807, zeg maar 'oneindig veel'
Knappe jongen als jij dit leven nog zoveel records weet aan te maken.
Gokje: Je bent menselijk en denkt heel erg klein en een database is maar een stukje software en denkt onvoorstelbaar groot.
Conclusie: Ga normaliseren.
Edit:
Ik heb oevrigens al een eenvoudige oplossing gemaakt,
Doe jezelf een plezier en vergeet deze onzin. Dit is echt een blunder van de eerste orde, ga dit niet gebruiken, het slaat echt nergens op.
