sql >> Database teknologi >  >> RDS >> Mysql

MySQL - Organisering af databaseindhold (Sports League)

Av. Du har påtaget dig et stort arbejde. Er du helt sikker på, at intet, du skal gøre, ikke kan gøres af noget, der allerede er tilgængeligt? Nå, hvis du er sikker, så læs videre.

For det første er den sværeste del af det, du vil gøre, at administrere din brugeradgang. Jeg vil råde dig til at starte med at skrive dit brugerstyringsmodul, før du går videre.

For hvad du ønsker, virker det sandsynligt, at Drupal eller et af de andre senior CMS-systemer ville være en fantastisk måde at bootstrap systemet på. Drupal vil håndtere din brugeradministration lige ud af boksen (eller med minimale problemer), og du kan skrive resten af ​​din kode som statiske noder. Dette gør det også nemt at tilføje blogs, fora, nyheder og at administrere mailinglister osv.

Som angivet i kommentarerne ovenfor, skal du holde dine data samlet. det ville være godt at beholde data til historiske sammenligninger også.

Hvis du ikke forlænger et CMS, efter du er kommet tilbage fra psykiateren, har du brug for noget i retning af:

  1. header-fil for at få adgang til db'en og kontrollere for brugergodkendelse.

  2. footer-fil for at vise dine data

  3. individuelle sidefiler for at præsentere eller få dine data.

Databasestrukturen til håndtering af brugerne (minimum) bør være IRO:

Person - details of individual users
username - link person to a username
email - email addresses
club - sports club details
password - passwords
logon - record of logon attempts
role - record of role of individuals in your site
permissions - list of required permissions to access areas of the site
role_permissions - default permissions for each role
person_role - link person to role
person_permissions - link person to permissions (only needed if some individuals need extra permissions not given routinely by their role)
club_person; person_email; - link people to clubs and to their email addresses.

For at håndtere kampene skal du bruge:

team - team name, group and club reference
grouping - list of groups eg by age.  
divisions. - list of divisions
venue - list of venues.  Include GPS!!!
match - division, grouping, team1, team2, venue, date, time
result - team1 reported result, team 2 reported result, approved result (you may need to intervene!) match.

Som du kan se, har du brug for et par borde, men DU MÅ IKKE prøve at lave de sjove ting med de faktiske hold, FØR du har din brugeradgang til at fungere korrekt.

Det jeg har skitseret til dig er en db i normal form. Ingen tekstdata duplikeres, og dataene er nemme at hente, indeksere og vise. Jeg føler, at dette spørgsmål er for bredt til SO, da det er lidt uden for rækkevidde at designe en database til dig, men jeg tror, ​​at det generelle format er nyttigt.

Hver tabel bør kun indeholde unikke nødvendige data, f.eks.:

Person:  personid int, surname, forename, style, whenadded, whoadded, inuse
email:   emailid, email, whenadded, whoadded, inuse
email_person:  emailpersonid,emailid,personid, whenadded,whoadded,inuse

Dette gør det muligt for flere personer at dele én e-mail og flere e-mails, der kan anvendes på én person uden tekstduplikering. ID'er skal være type INT AUTO_INCREMENT PRIMARY KEY frem for SERIAL, da dette sparer en masse lagerplads, og du vil aldrig udfylde en INT i denne applikation.

De andre tabeller skal oprettes på samme måde. De whoadded og whenadded kolonner er valgfri og ret lager sultne, men kan være meget nyttige. inuse er essentielt sæt dette til en BOOL, og du kan fjerne hold uden at slette dem - dataene går ikke tabt. En whenremoved og whoremoved er også nyttig til revision.

Et ord om adgangskoder - sørg for at gemme disse som en SALTET HASH. Hvis du gør dette, når dit websted er hacket, vil ingen have adgangskoden, som de også bruger til deres netbank, afsløret. Folk er ofte idioter. Du skal passe på dem.

Som sagt lidt uden for rækkevidde, så jeg slutter svaret der - det giver dig som anmodet den grundlæggende skitse af en 4. Normal Form Db, der vil være robust og udvidelig, men som overlader dig til at gøre arbejdet. Hvorfor ikke stille flere spørgsmål, hvis problemet viser sig at være for svært.

Held og lykke.

TILFØJET:

DIY Framework:

Hvis du ikke vil lære at bruge et af de eksisterende rammer eller CMS, skal du skrive dit eget. Mærkeligt nok er dette faktisk meget nemt.

header.php:

<?PHP
$mysqli=new mysqli(credentials....)//connect to database and present a mysqli or pdo object.
session_start(); //open a session
//you will need to authenticate your session here - see below
?>

footer.php:

<HTML>
<HEAD>
<TITLE>
<?PHP echo $pagetitle;?>
</TITLE>
</HEAD>
<BODY>
<?PHP echo $content;?>
</BODY>
</HTML>

Disse bruges af mypage.php:

<?PHP
require("header.php");
//do some stuff that generates $content
$pagetitle="mypage.php";
require("footer.php:);
?>

Det skal understreges, at dette er det absolutte minimum, du har brug for, og det er virkelig ulækkert - det er blot præsenteret for at vise, hvordan dette skal startes, ikke et eksempel på ideel kode. Det vil dog virke.

Nøglen er at oprette en header, der præsenterer de variabler, du skal bruge, såsom en db-forbindelse, brugernavn, brugerlogonstatus osv. og en sidefod, du kan indtaste detaljer i for at præsentere dataene. Sidefoden er det eneste sted, hvor du kombinerer HTML og PHP.

Brug din $_SESSION til at gemme oplysninger, der skal forblive mellem siderne.

Disse filer kan være lige så enkle eller komplekse, som du vil - jeg oprettede for min egen alder siden, der kontrollerer brugeren og sessionen adskillige og kan vise scripts, brugerdefinerede CSS-filer og sådan i sidefoden. Det er ikke svært at gøre, hvis du starter enkelt og bygger videre, som du har brug for. SO vil være her for at hjælpe dig.

Et advarselsord:Selvom du kan starte meget enkelt, har det, du prøver at gøre, ben og vil komme ud af hånden. Kontroller venligst din kode, når du har den oppe at køre for at sikre dig, at du ikke utilsigtet har inkluderet sikkerhedsfejl. Det er meget nemt at inkludere disse, når du går ind i et projekt og har brug for en hurtig løsning, og de kan være djævelsk svære at få øje på senere, medmindre du leder efter dem.



  1. Sphinx vs. MySql - Søg gennem listen over venner (effektivitet/hastighed)

  2. Gentagende begivenheder den n. ugedag i hver måned

  3. Hvordan laver man en indre deltagelse i django?

  4. Laravel-migrering (fejlnr.:150 Foreign key constraint er forkert dannet)