sql >> Databáze >  >> RDS >> Mysql

MySQL – organizace obsahu databáze (Sports League)

Au. Vzal jste si velkou práci. Jste si naprosto jisti, že nic, co se chystáte udělat, nemůže udělat něco, co je již k dispozici? Pokud jste si jisti, čtěte dále.

Za prvé, nejtěžší částí toho, co chcete udělat, je správa vašeho uživatelského přístupu. Doporučil bych vám, abyste začali sepsáním modulu správy uživatelů, než budete pokračovat.

Pro to, co chcete, se zdá pravděpodobné, že Drupal nebo některý z dalších vyšších CMS systémů by byl skvělý způsob, jak zavést systém. Drupal se postará o vaši správu uživatelů hned po vybalení (nebo s minimálními problémy) a zbytek kódu můžete napsat jako statické uzly. To také usnadňuje přidávání blogů, fór, zpráv a správu seznamů adresátů atd.

Jak je uvedeno v komentářích výše, musíte mít svá data pohromadě. bylo by dobré uchovávat data i pro historická srovnání.

Pokud neprodloužíte CMS, poté, co se vrátíte od psychiatra, budete potřebovat něco ve smyslu:

  1. záhlaví souboru pro přístup k db a kontrolu ověření uživatele.

  2. zápatí pro zobrazení vašich dat

  3. jednotlivé soubory stránek k prezentaci nebo získání vašich dat.

Struktura databáze pro manipulaci s uživateli (minimálně) by měla být 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.

Ke zpracování zápasů budete potřebovat:

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.

Jak vidíte, potřebujete pár stolů, ale NESMÍTE se pokoušet dělat zábavné věci se skutečnými týmy, DOKUD nebudete mít svůj uživatelský přístup správně fungující.

To, co jsem vám načrtl, je db v normální podobě. Žádná textová data se neduplikují a data lze snadno načíst, indexovat a zobrazit. Mám pocit, že tato otázka je pro vás příliš široká, protože navrhování databáze pro vás je trochu mimo rozsah, ale myslím si, že obecný formát je užitečný.

Každá tabulka by měla obsahovat pouze jedinečná nezbytná data, např.:

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

To umožňuje více lidem sdílet jeden e-mail a více e-mailů použít pro jednu osobu bez duplikace textu. ID by měla být typu INT AUTO_INCREMENT PRIMARY KEY spíše než SERIAL, protože to šetří spoustu úložného prostoru a v této aplikaci nikdy nevyplníte INT.

Ostatní tabulky by měly být vytvořeny stejným způsobem. Sloupce whoadded a whenadded jsou volitelné a poměrně náročné na úložiště, ale mohou být velmi užitečné. inuse je nezbytné, nastavte toto na BOOL a můžete týmy odstranit, aniž byste je smazali - data se neztratí. A whenremoved a whoremoved je také užitečné pro audit.

Pár slov k heslům – ujistěte se, že je ukládáte jako SALTED HASH. Pokud to uděláte, při napadení vašeho webu nebude nikomu odhaleno heslo, které také používá pro své internetové bankovnictví. Lidé jsou často idioti. Musíte se o ně starat.

Jak jsem řekl, trochu mimo rozsah, takže odpověď ukončím tam - poskytuje vám, jak bylo požadováno, základní obrys 4. normálního formuláře Db, který bude robustní a rozšiřitelný, ale nechá vás dělat práci. Proč se nepoložit více otázek, pokud se problém ukáže jako příliš těžký.

Hodně štěstí.

PŘIDÁNO:

DIY Framework:

Pokud se nechcete učit používat některý ze stávajících frameworků nebo CMS, budete si muset napsat svůj vlastní. Kupodivu je to ve skutečnosti velmi snadné.

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>

Ty používá mypage.php:

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

Je třeba zdůraznit, že toto je naprosté minimum, které budete potřebovat, a je to opravdu hnusné – je to jen ukázáno, jak by se to mělo začít, nikoli příklad ideálního kódu. Bude to fungovat.

Klíčem je vytvoření záhlaví, které představuje proměnné, které budete potřebovat, jako je připojení k databázi, uživatelské jméno, stav přihlášení uživatele atd., a zápatí, do kterého můžete zadat podrobnosti pro prezentaci dat. Zápatí je jediné místo, kde kombinujete HTML a PHP.

Použijte svou $_SESSION k uložení informací, které musí mezi stránkami přetrvávat.

Tyto soubory mohou být jednoduché nebo složité, jak chcete – před dávnými lety jsem vytvořil své vlastní, které provádějí několik kontrol uživatele a relace a mohou zobrazovat skripty, vlastní soubory CSS a podobně v zápatí. Není těžké to udělat, pokud začnete jednoduše a budete dále stavět, jak potřebujete. SO bude tady, aby vám pomohl.

Jedno slovo opatrnosti:ačkoli můžete začít velmi jednoduše, to, o co se snažíte, má nohy a vymkne se vám z rukou. Poté, co jej zprovozníte, zkontrolujte svůj kód, abyste se ujistili, že jste nedopatřením nezahrnuli bezpečnostní chyby. Je velmi snadné je zahrnout, jakmile se dostanete do projektu a potřebujete rychlou opravu, a později může být ďábelsky těžké najít, pokud je nebudete hledat.



  1. Rails 3.1 - Pushing to Heroku - Chyby při instalaci postgres adaptéru?

  2. tabulka připojení mysql sama o sobě

  3. Příklad hromadného sběru Oracle PL/SQL s výjimkami uložení

  4. Dotaz na řádky, pro které neexistuje klíč metadat