Autor Zpráva
janbarasek
Profil
#1 · Zasláno: 23. 4. 2014, 18:24:17
Odpovědět Citovat
Ahoj,
pracuji na webové aplikaci na prodej online kurzů vysokoškolské matematiky a zasekl jsem se na navržení architektury - resp. mě napadlo víc řešení a nevím, které je nejlepší.
Mám tabulku uživatelů, kde mám kromě hromady informací sloupeček "kurzy", kde si eviduji, které kurzy uživatel vlastní. Dělám to tak, že vyjmenovávám ID kurzů a odděluji je "svislítkem", příklad syntaxe: 
1|3|4|5

Zadavatel zakázky po mě ale chce nějakou ochranu proti zneužívání systému. První z nich spočívá v tom, že každý kurz je časově omezen (na jak dlouho se kupuje). Samotné uložení informace bych řešil asi číslem typu INT, které bude uvádět počet dní do konce a jednou za den to cron nějak přepočítá (sice to bude náročné na výkon, ale když to bude jednou za noc, tak to není zas tak hrozné). Přemýšlím ale, jak mám rozvrhnout tabulku, kde bych toto uchovával. Napadlo mě dosti "prasácké" řešení, že bych uživatele vypsal na řádky a kurzy na sloupce, příklad: 
  ID  | kurz_1 | kurz_2 | kurz_3 | kurz_4 | kurz_5
--------------------------------------------------
 1    | 60     | 30     | 45     | 0      | 14
 2    | 50     | 0      | 29     | 26     | 34
 3    | 14     | 56     | 34     | 32     | 0
 4    | 0      | 81     | 72     | 8      | 25

Asi by to fungovalo, ale při myšlence, že těch kurzů bude v budoucnu víc a pro každý nový kurz budu muset vést nový sloupeček, ... no. Ale zase by se z toho dobře dalo číst, protože bych si vytáhl vždy to, co je potřeba. Napadá někoho z vás, jak by se toto dalo řešit, abych mohl jednoduše cokoli přečíst a změnit?
Součástí každého kurzu jsou videa (30 a víc videí) a zákazník požaduje, abych evidoval počet zhlédnutí pro každého uživatele - údajně, aby se dal jednoduše monitorovat případný podvod, že divák "vykecá" přihlašovací údaje někomu jinému.
Kurzů je hodně, videí je ještě o mnoho víc. Napadá vás řešení, jak bych to mohl evidovat zde? Pokud bych si pro každé video udělal sloupeček, tak by se mi asi zbláznila databáze a každé čtení by trvalo dlouhé sekundy, což nechci. Potřebuji něco, co bude ideálně reagovat v rámci mikrosekund.

Mě jedno řešení napadlo: Vůbec to neprogramovat, ale to nemůžu... prostě to tam musí být :(

Předem děkuji za jakoukoli radu.
juriad
Profil
#2 · Zasláno: 23. 4. 2014, 18:38:40 · Upravil/a: juriad o 6 minut později
Odpovědět Citovat
Jdeš na to úplně blbě. Kdykoli máš tendenci cpát několik hodnot do jednoho sloupečku, případně přidávat nové sloupečky, vytvoř novou tabulku. 

účastníci (
  id INT,
  jméno VARCHAR,
  heslo VARCHAR,
  PRIMARY KEY (id)
)

kurzy (
  id INT,
  název VARCHAR,
  cena VARCHAR,
  PRIMARY KEY (id)
)

videa (
  id INT, 
  nazev VARCHAR, 
  kurz_id INT,
  PRIMARY KEY (id),
  FOREIGN KEY (kurz_id) REFERENCES kurzy (id)
)

zaplacené_kurzy (
  id INT,
  účastník_id INT,
  kurz_id INT,
  platnost_od DATE,
  platnost_do DATE,
  PRIMARY KEY (id),
  FOREIGN KEY (účastník_id) REFERENCES účastníci (id),
  FOREIGN KEY (kurz_id) REFERENCES kurzy (id)
)

zhlédnutí_videa (
  účastník_id INT,
  video_id INT,
  datum DATETIME,
  FOREIGN KEY (účastník_id) REFERENCES účastníci (id),
  FOREIGN KEY (video_id) REFERENCES videa (id)
)

Neuvažuj nad výkonem! Dokud nebude sto tisíc videí a stejný počet uživatelů, tak to databáze zvládne. S výjimkou tabulky zhlédnutí_videa, kde by možná bylo lepší nahradit sloupeček datum za počet.
Tori
Profil
#3 · Zasláno: 23. 4. 2014, 19:43:12
Odpovědět Citovat
janbarasek:
„zákazník požaduje, abych evidoval počet zhlédnutí pro každého uživatele - údajně, aby se dal jednoduše monitorovat případný podvod, že divák "vykecá" přihlašovací údaje někomu jinému.“
Na to by se možná dalo využít i Google Analytics - přidat tam nějakou proměnnou pro identifikaci uživatele (lze-li to), a pak zjistit, jestli se třeba tentýž uživatel nepřihlásil ve dvě z Brno a o půl třetí z Liberce.
janbarasek
Profil
#4 · Zasláno: 23. 4. 2014, 20:01:49
Odpovědět Citovat
Tori:
„Na to by se možná dalo využít i Google Analytics - přidat tam nějakou proměnnou pro identifikaci uživatele (lze-li to), a pak zjistit, jestli se třeba tentýž uživatel nepřihlásil ve dvě z Brno a o půl třetí z Liberce.“
To se mi nelíbí, protože to potřebuji automatizovat. Každý den tam má 60 nových registrací a při představě, že to budu nějak ručně kontrolovat... no, to potěš pandu. :) Stačí mi, že ručně autorizuji příchozí platby (to bych sice mohl udělat automaticky, ale protože jde o peníze, tak nad tím potřebuji mít co nejlepší přehled a případně ihned kontaktovat zákazníka).
_es
Profil
#5 · Zasláno: 23. 4. 2014, 20:29:02
Odpovědět Citovat
janbarasek:
> Dělám to tak, že vyjmenovávám ID kurzů a odděluji je "svislítkem", příklad syntaxe: 
1|3|4|5
To je zlý návrh. Jeden riadok by mala tvoriť dvojica id užívateľa a id kurzu - jeden užívateľ by teda bol vo viacerých stĺpcoch.

„Samotné uložení informace bych řešil asi číslem typu INT, které bude uvádět počet dní do konce a jednou za den to cron nějak přepočítá“
Prečo tam nedáš konkrétny časový údaj dokedy je kurz platný a nebudeš tak musieť nič prepočítavať?

„Pokud bych si pro každé video udělal sloupeček, tak by se mi asi zbláznila databáze a každé čtení by trvalo dlouhé sekundy, což nechci.“
Tých videí snáď nebudú miliardy. V databáze snáď môžeš vhodne použiť indexy.

Zdá sa mi, že si si na spoľahlivé vypracovanie platenej (asi) zákazky na databázovú aplikáciu nenaštudoval dostatok základov z databáz.
janbarasek
Profil
#6 · Zasláno: 23. 4. 2014, 22:25:37
Odpovědět Citovat
_es:
„Prečo tam nedáš konkrétny časový údaj dokedy je kurz platný a nebudeš tak musieť nič prepočítavať?“
Protože s tím potřebuji dále pracovat, budu to ukládat jako Universal time, s tím se dělají všechny možné operace snadno. Snad do roku 2038 ta databáze už nebude existovat... ;)

„Tých videí snáď nebudú miliardy.“
Aktuálně jich je 230 a každý týden se přidá dalších 5-10 videí a nevylučuji, že by se v budoucnu mohla rychlost ještě o něco zvýšit.

„Zdá sa mi, že si si na spoľahlivé vypracovanie platenej (asi) zákazky na databázovú aplikáciu nenaštudoval dostatok základov z databáz.“
Chápu obecné principy fungování databází, vím co k čemu je. Jenom jsem si v tomto případě nebyl jistý a nerad bych vytvořil něco, co by za čas přestalo fungovat z důvodu velkého objemu dat. Mám rád bezúdržbové programy, co fungují mnoho let bez jakéhokoli servisního zásahu.
juriad
Profil
#7 · Zasláno: 23. 4. 2014, 22:58:34
Odpovědět Citovat
janbarasek:
Zkus si udělat nějaké performance testy a naplň si databázi stotisíci záznamy. Bude-li ti výsledná rychlost stačit (myslím, že bude), tak bych víc neřešil a raději zvolil řešení, které je přehledné, než takové, které je ultra-hyper-mega-rychlé.
Pro porovnání, tato diskuse má skoro milion příspěvků v 150 tisících tématech. Myslíš, že je pomalá?

Ukládej všechny časy jako DATE, či DATETIME. Můžeš pak v dotazech používat specializované funkce na práci s daty. Rychlostí ani velikostí to nebud o moc horší, ale bude to o hodně pohodlnější.

Tvé nadšení pro bezúdržové systémy chápu, ale tady není obava na místě. Znovu říkám, odhadni maximální počet záznamů a zkus si na testovacích datech, jak to bude rychlé.
_es
Profil
#8 · Zasláno: 24. 4. 2014, 09:15:58
Odpovědět Citovat
janbarasek:
„Protože s tím potřebuji dále pracovat, budu to ukládat jako Universal time, s tím se dělají všechny možné operace snadno.“
Predsa aj čas, do ktorého je kurz platný, môžeš uložiť v UTC. A budeš pracovať len s rozdielmi dvoch časov, čo je na úrovni databázy len rozdiel dvoch čísel.
Časová prodleva: 10 let

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0