sql >> Databasteknik >  >> RDS >> Mysql

MySQL - Organisera databasinnehåll (Sports League)

Aj. Du har tagit på dig ett stort jobb. Är du helt säker på att inget du ska göra inte kan göras av något som redan finns tillgängligt? Tja, om du är säker, läs vidare.

För det första är den svåraste delen av det du vill göra att hantera din användaråtkomst. Jag rekommenderar att du börjar med att skriva din användarhanteringsmodul innan du går vidare.

För vad du vill, verkar det troligt att Drupal eller något av de andra seniora CMS-systemen skulle vara ett bra sätt att bootstrap systemet. Drupal kommer att hantera din användarhantering direkt (eller med minimala problem) och du kan skriva resten av din kod som statiska noder. Detta gör det också enkelt att lägga till bloggar, forum, nyheter och att hantera e-postlistor etc.

Som nämnts i kommentarerna ovan måste du hålla ihop dina data. det skulle vara bra att behålla data för historiska jämförelser också.

Om du inte utökar ett CMS, efter att du har kommit tillbaka från psykiatern, behöver du något i stil med:

  1. header-fil för att komma åt db och kontrollera användarautentisering.

  2. sidfotsfil för att visa dina data

  3. enskilda sidfiler för att presentera eller hämta dina data.

Databasstrukturen för att hantera användarna (minst) bör vara 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.

För att hantera matchningarna behöver du:

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 behöver du en hel del bord, men DU FÅR INTE försöka göra det roliga med de faktiska lagen FÖRrän du har din användaråtkomst fungerar som den ska.

Det jag har skissat på åt dig är en db i normal form. Ingen textdata dupliceras och data är lätt att hämta, indexera och visa. Jag tycker att den här frågan är för bred för SO eftersom att designa en databas åt dig är lite utanför räckvidden men jag tror att det allmänna formatet är användbart.

Varje tabell bör endast innehålla unika nödvändiga data, t.ex.:

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

Detta gör att flera personer kan dela ett e-postmeddelande och flera e-postmeddelanden kan tillämpas på en person utan textduplicering. ID:n bör vara typ INT AUTO_INCREMENT PRIMARY KEY snarare än SERIAL eftersom detta sparar mycket lagringsutrymme och du kommer aldrig att fylla i en INT i det här programmet.

De andra tabellerna bör skapas på samma sätt. Kolumnerna whoadded och whenadded är valfria och ganska lagringshungriga men kan vara mycket användbara. inuse är väsentligt sätt detta till en BOOL och du kan ta bort team utan att ta bort dem - data går inte förlorad. En whenremoved och whoremoved är också användbar för granskning.

Ett ord om lösenord - se till att du lagrar dessa som en SALTAD HASH. Om du gör detta, när din webbplats hackas, kommer ingen att ha det lösenord som de också använder för sin internetbank. Folk är ofta idioter. Du måste ta hand om dem.

Som sagt, lite utanför räckvidden så jag avslutar svaret där - det ger dig som begärt grundkonturen av en 4:e Normal Form Db som kommer att vara robust och utdragbar men som låter dig göra jobbet. Varför inte ställa fler frågor om problemet visar sig vara för svårt.

Lycka till.

TILLÄGG:

DIY Framework:

Om du inte vill lära dig att använda något av de befintliga ramverken eller CMS, måste du skriva ditt eget. Konstigt nog är detta faktiskt väldigt enkelt.

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>

Dessa används av mypage.php:

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

Det bör betonas att detta är det absoluta minimum du behöver och är verkligen tråkigt - det presenteras bara för att visa hur detta bör börja, inte ett exempel på idealisk kod. Det kommer dock att fungera.

Nyckeln är att skapa en rubrik som presenterar de variabler du behöver, såsom en db-anslutning, användarnamn, användarinloggningsstatus etc. och en sidfot du kan ange detaljer i för att presentera data. Sidfoten är det enda stället där du kombinerar HTML och PHP.

Använd din $_SESSION för att lagra information som måste finnas kvar mellan sidorna.

Dessa filer kan vara hur enkla eller komplexa du vill - jag skapade mina egna för länge sedan som gör flera kontroller av användaren och sessionen och kan visa skript, anpassade CSS-filer och sådant i sidfoten. Det är inte svårt att göra om du börjar enkelt och bygger på som du behöver. SO kommer att vara här för att hjälpa dig.

Ett varningens ord:även om du kan börja väldigt enkelt, har det du försöker göra ben och kommer att gå ur hand. Granska din kod när du har den igång för att se till att du inte oavsiktligt har inkluderat säkerhetsbrister. Det är väldigt lätt att inkludera dessa när du går in i ett projekt och behöver en snabb fix och de kan vara djävulskt svåra att upptäcka senare om du inte letar efter dem.



  1. Varför detta databasmigreringsfel efter att jag uppgraderat min version django-mptt?

  2. Kapslade loopar och Performance Spools

  3. PHP MySQL PDO lastInsertID orsakar ett allvarligt fel

  4. CakePHP 3:Bästa praxis för tillfälliga SQL-tabeller