ik zit met een vraagje, weet iemand van jullie misschien een
manier om in te loggen die hier aan voldoet? :
Ik heb een database met 10 tables... (plus een leden table)
alle leden hebben een database
pietje heeft database pietje
jantje heeft database jantje
als men inlogt wil ik dat ze ALLEEN hun eigen database gegevens zien..
dat lukt me nu niet helemaal.. en stukje van wat ik had leek mij wel logisch
maar dat werkte dus niet... namelijk:
Nee hoor, bij je mysql_connect() maakt die al verbinding en die verbinding gebruikt die elke keer. Hij gebruikt steeds de laatst geopende verbinding ;)
of zo:
$verbind = mysql_select_db($gegevens['username'],mysql_connect('xxx','xxx','xxx');
Maar je kan het beter volgens de manier van wes doen, en dan met een WHERE alleen de bestellingen van hun zelf laten zien.
<?php
session_start();
$verbind = @mysql_select_db($gegevens['username'],mysql_connect('xxx','xxx','xxx');
if(!$verbind) {
die("Er is geen database connectie gemaakt...");
}
$select = "SELECT * FROM bestellingen WHERE filliaal_id = '".$_SESSION['id']."'"; //of hoe je de filliaal dan ook aanroept.
$result = mysql_query($select) or die("Er is iets mis gegaan...");
?>
O ik het het niet helemaal goed uitgelegd zie ik... het is niet
letterlijk het bestelsysteem... maar het is het systeem die als
archief dient... alle bestellingen worden opgeslagen met klant
gegevens endergelijke zodat als de bestelling er is gebeld
kan worden naar de klant...
ik post wel even een overzicht van hoe het eruit ziet in de db..
dit is de query voor het opslaan van het invul formulier.. dan zie
je meteen alle velden in de nu hetende tabel 'bestel'
Dit datamodel klopt van geen kanten, dit heeft weinig tot niets met een relationele database te maken.
Wanneer jij een goed systeem wilt maken, zul je echt terug moeten naar de tekentafel en de complete database opnieuw ontwerpen. Ga beginnen met normaliseren, dat is een absolute vereiste.
Ik raad je heel sterk af om verder te gaan met het huidige systeem. De basis is niet goed, hierdoor zul je allerlei rare fratsen moeten uithalen om de boel toch enigzins werkend te krijgen. De kans dat dit uiteindelijk hopeloos fout gaat, is levensgroot.
o we hebben al bijna een jaar een systeem draaien waaruit ik deze query heb gehaald en tot nu toe nog geen probleem gehad...
ik leer op school inderdaad ook over in normaalvorm zetten maar dat
wilde ik eigenlijk pas helemaal aan het einde gaan doen als het inloggen systeem eenmaal werkt..
Volgens mij is het niet compleet, een Artikel heeft ook een leverancier, dit sla je nergens op. Daar zal een aparte tabel voor moeten komen.
Inkoop- en verkoopprijs lijken mij handig, evenals het btw-percentage.
Geen idee of er nog meer eigenschappen zijn van een artikel, maar de huidige opzet is wat magertjes.
Het adres van de klant sla jij op in 1 kolom. Dat is niet handig, nu kun je nooit achterhalen in welke plaatsen jouw klanten zich bevinden, laat staan dat de database eist dat er een geldige postcode en woonplaats worden opgegeven.
De tabel garantie is nergens aan gekoppeld. Je hebt geen idee wie aanspraak maakt op garantie en wanneer deze onbekende persoon het artikel heeft gekocht.
En over koppelingen gesproken, er is helemaal geen verband tussen de tabellen, er is helemaal geen sprake van een relationele database.
Kortom, stap 1 heb je gemaakt, de overige stappen ontbreken nog.
Normaliseren doe je niet even in een halfuurtje, je bent zo maar een dag verder voor een inkoop/verkoop-systeem. En zelfs dan zul je nog fouten tegenkomen.
