Autor Zpráva
BunnyBugs
Profil *
Zdravím,
už zase nevím, jak na to, prosím o radu. Mám tento SELECT:

$VyjezdomerTop = mysql_query("SELECT `jmeno`, SUM(`vzdalenost`) as `celkem` FROM `prehled` WHERE `sezona` = '2013-14' ".
                                                    "GROUP BY `jmeno` ORDER BY `celkem` DESC LIMIT 10");

V DB je možnost duplicitních řádků, ale já bych potřeboval, aby to celkový součet udělalo jen pokaždé z jednoho řádku, i kdyby tam byly stejné třeba 4.
Je toto nějak možné? Když jsem použil DISCINCT (`jmeno`), neudělalo to nic a když u SUM(DISCINCT(`vzdalenost`)), odečetlo to i vzdálenosti, které jsou u některých akcí stejné.
lionel messi
Profil
BunnyBugs:
Malo by pomôcť doplnenie klauzuly HAVING:
SELECT `jmeno`, SUM(`vzdalenost`) as `celkem` 
FROM `prehled` 
WHERE `sezona` = '2013-14'
GROUP BY `jmeno`
HAVING COUNT(`jmeno`) < 2
ORDER BY `celkem` DESC
LIMIT 10

(netestované)
BunnyBugs
Profil *
lionel messi:
Tak tohle by asi bylo dobré, ale nějak to nelze aplikovat u mě. Jde o to, že `sezona` obsahuje několik `akce`. Tudíž se `jmeno` objevuje v tabulce několikrát a ta podmínka HAVING COUNT () mi odstraní vše a nechá jen ten první výskyt jména.
Já bych ale potřeboval, aby to nepočítalo pouze duplicitu v dané akci, nikoliv v celé sezóně.
juriad
Profil
BunnyBugs:
Tak si napiš SELECT, který duplicty odstraní (respektive je nevrátí), a nad ním pak prováděj SUMování (budeš mít dotaz s poddotazem).
Alphard
Profil
A ty duplicity jsou jinak validní a jen je nechcete v tomto konkrétním součtu?
Protože jestli dotaz souvisí s návrhem popsaným v Výpis z DB s proměnným počtem sloupců, tak v tabulce prehled ta vzdálenost vůbec být nemá. Ta má být u akcí, jak jste uváděl.
BunnyBugs
Profil *
Alphard:
Na jednu akci se přihlásí registrovaný uživatel pod svým jménem, který je zařazen do soutěže o nejvíc najetých km. Může však přihlásit pod svým jménem k dané akci i kamaráda, který není registrován, tudíž mi vzniknou na jednu akci dvě stejná jména, to omezené není, ale právě mi to pak počítá ty kilometry dvakrát, což je chyba. Jedná se mi tedy o nesečtení duplicity v jedné akci.
Tabulka prehled související s předchozím popsaným návrhem takhle samozřejmě nevypadá, tu jsem si teď jen zjednodušil pro zkoušení správné funkčnosti.

juriad:
Tomu teď trochu nerozumím :(
Alphard
Profil
BunnyBugs:
Může však přihlásit pod svým jménem k dané akci i kamaráda, který není registrován, tudíž mi vzniknou na jednu akci dvě stejná jména
To je chybný návrh databáze. Viděl bych to na 2 sloupce, jeden sloupec bude odpovídat skutečnému závodníkovi (ten bude unikátní) a druhý může ukládat, kdo ho přihlásil. Neregistrovaní závodníci nejsou problém, ale přihlašovaní s tím musí počítat a musí tam být možnost přihlásit neregistrovaného závodníka. Není rozumné přihlašovat je pod svým účtem.
BunnyBugs
Profil *
Alphard:
Jj, samozřejmě neregistrovaní se mohou hlásit také.
Nejde tam o závodníky, ale o obsazenost autobusu. Z ohlasů původně funkčních stránek si lidé stěžovali, že když chtějí jet s kamarády, musí každého přihlašovat zvlášť a vypisovat jednotlivá jména, proto jsem při přihlášení, ať už registrovaných či ne, nastavil možnost přihlásit až 5 míst, které se poté zobrazí pod se stejným jménem toho, kdo přihlašuje k dané akci. Jména samozřejmě znát nepotřebuji, jen těch, kteří jsou zařazeni do soutěže nejvíce ujetých km. Do teď jsem toto počítal (zadával) ručně do excelové tabulky (viz náhled toho předchozího příspěvku), kterou jsem pak dával pomocí IFRAME do stránek z excelu on-line. A teď to celé předělávám a rád bych to zautomatizoval, proto hledám schůdné řešení pro výpis TOP10 dle tohoto vlákna a pak na celou tabulku dle předchozího vlákna.
Alphard
Profil
To co popisujete zní z pohledu uživatele rozumně, ale implementačně je to řešeno chybně. Klidně povolte registrovat si více míst, ale není to důvod dávat si duplicity do databáze.

Nevidím do celého systému, ale konkrétně pro tuto situaci se nabízí přidat sloupec s počtem rezervovaných míst. Když si někdo rezervuje 4 místa, přidá se jediný záznam s tím, že jsou rezervována 4 místa.
BunnyBugs
Profil *
Alphard:
Kdyžtak klidně tykat, neřipadám si starý, i když už nejmladší nejsem :D
No jde o to, že se to aktuálně vždy vypíše do tabulky přihlášených, tedy jedno jméno, jeden řádek, aby byla ihned vidět kapacita naplněnosti autobusu. Mám to ošetřené zatím tak, že pokud někdo objedná více míst, tak se od druhého řádku dopíše automaticky číslovka. Resp. když nějaké jméno přihlašuje třeba 3 místa, řádky v tabulce vypadají asi takto: jmeno, jmeno(2), jmeno(3). Pak bych ani nemusel řešit ty duplicity, to je v pohodě. Problém začne, když se to dotyčné jméno přihlásí znovu, to mi pak vzniknou dva identické řádky.
Teď mě ještě napadlo, jestli by nebylo jednodušší, kdyby při přihlášení k akci se kontrolovala existence jména na danou akci? Pak by musel přihlašující zadat jiné jméno a tím by byla otázka duplicit vyřešena. Bylo by to takhle lepší?


Rád bych ukázal náhled stránek, ale z původního serveru a DB je to smazané, nefunkční a na novým to ještě nemám, dokud to nebudu mít kompletní.
Bohužel byla chyba, že původní DB byla tvořena jedinou tabulkou (vyjma uživatelů) se všemi údaji, takže to teď musím celé rozdělovat a přizpůsobit lepší a snadnější verzi.
Nejsem žádný "profík", ani se tím neživým, dělám to jen proto, že mě to baví a veškeré znalosti, které zatím mám, čerpám jen z různých kódů a této diskuze a návodů, protože angličtina mě trochu minula. Jak jsem říkal, nejsem zrovna nejmladší :P
Alphard
Profil
K té kapacitě při vypisování tabulky. Ve výpise se to klidně může duplikovat (jestli vám to vyhovuje), ale ani to by snad nemuselo být žádoucí. Já bych to udělal nějak takto:
Jméno     | Počet
-----------------------
Markéta   | 4 x
Eliška    | 1 x
Anna      | 2 x
-----------------------
Celkem    | 7 x

kdyby při přihlášení k akci se kontrolovala existence jména na danou akci?
Určitě by to tak mělo být. Vícenásobné přihlašování by nemělo být povoleno. Ani ne tak kvůli duplicitám, ale kvůli správnosti návrhu.

Tabulky pro nové entity se nebojte neboj přidávat, relační databáze jsou tak navrženy. Kdyžtak www.manualy.net/article.php?articleID=13.
BunnyBugs
Profil *
Alphard:
O.K. díky za rady. Vyřeším to tedy tím, že nepovolím duplicity a v případě přihlášení více účastníku jedním formulářem, bude muset ke každému místu připsat další jméno. Tím budu mít vyřešený výpis TOP10 :)
Pak ale ještě zůstává nedořešenou otázkou, jak přesně vyřešit tu celkovou tabulku :(

Ohledně relační DB si myslím, že to mám už v pořádku, z jedné velké jsem udělal čtyři (uzivatele, mista, akce, prehled.

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