Hívj fel telefonon és lediktálom a megoldást .

Nem tudnád inkább leírni?

Itt egy remek összefoglalás: [link]

=Kilroy was here============================ooO=*(_)*=Ooo=======

Sziasztok!

Lenne egy kis gondom.

Van egy lekérdezésem amivel megkapok minden szükésges adatok kivéve néhányat, oda csak egy id-t kapok.

select title, user_id, summary url from entries ORDER BY letrejott DESC LIMIT 0 , 15

ezzel megkapom csökkenő sorrendben az első 15 cikket. Ezzel nincs is gond, de mint láltható csak user_id-t kapok ami egy másik táblában benne van a rendes név is, ennek a táblának a neve users és van benne user_id és username mező. Hogy tudnám azt megcsinálni, hogy az user_id helyett az username jelenjen meg.

Remélem érthető mit szeretnék.

Le megoldás:

select title, user_id, summary url ( select username from users where user_id = entries.user_id ) as username from entries ORDER BY letrejott DESC LIMIT 0 , 15

"hacsak nem jön a jó tündér break utasítás képében..."

Köszönöm , úgy néz ki jó lesz, már csak rossz táblából akarom szedni, mert több ugya olyan id is van benne, meg kell keresnem a megfeelő táblát.

Igazából mi az oka, hogy nem mondjuk INNER JOIN-nal csinálod?
Úgy értem, van valami előnye? Tulajdonképpen melyik a gyorsabb? Én úgy tudtam, hogy előnyösebb ilyen esetekben INNER JOIN-t használni, de lehet, hogy valamiről nem tudok.

Sk8erPeter

MS SQL-nél az inner join nagyságrendekkel gyorsabb, mint a beágyazott selectek. Oracle-lel nincs tapasztalatom.
Mondjuk amíg nem több százezres táblákon használsz ilyen alselectes beágyazásokat, addig szinte mindegy.

Én kérek elnézést!

Ja, köszi, én is így tudtam, de tudtommal MySQL-re is pontosan ugyanez igaz.
Egyébként a beágyazott selectnél valahogy szerintem jóval logikusabb is az inner join-os lekérdezés, már akkor is, amikor ránéz az ember a query-re, érti, hogy itt mi fog történni. Ennél az "alselectnél" először néztem, hogy ezt most miért úgy.

Sk8erPeter

Oracle-ben is gyorsabb a join, mint az alselect. Viszont ha csoportosító lekérdezést (group by) írsz, akkor az alselectnek lehet sebesség előnye.

=Kilroy was here============================ooO=*(_)*=Ooo=======

Nem gondoltam, hogy lehet olyan eset, ahol az alselect gyorsabb lehet, de végülis mittudomén talán előfordulhat ilyen.
Éppen a héten optimalizáltam egy kolléga kódját, aki szerette az alselecteket (mondjuk régivágású programozók még emlékeznek az SQL-ek hőskorára, amikor NEM is létezett inner join - 2000-es évek előtt). Mit ne mondjak százezres tételszámoknál (mind főselect, mind alselect több százezer sor) perceket lehetett nyerni, hogy 4-5 inner joinba rendeztem át a cuccot.

Tényleg és ti mit szóltok a temp táblákhoz? Múltkor ledöbbenve hallottam, hogy nem kellene használni őket. Szerintem ez hülyeség. Szerintetek? MSSQL alatt eléggé furcsállom, hogy ne kellene temp táblákat használni. Én még PostgreSQL, MySQL-ben is használok temp táblákat (8.0 felett, az ennél régebbiekben inkább csak elméleti lehetőség, mintsem gyakorlati).

Én kérek elnézést!

alselect: amikor sok táblát kell összekapcsolni, akkor szoktam használni (oracle), és az optimalizáló meg szokta hálálni. 1-2 órás futás helyett 10-20 perces eredmény.

temp tábla: A nem használat szerintem is hülyeség. Vagy mit javasolnak helyette? Esetleg memóriában tárolt tömböket?

=Kilroy was here============================ooO=*(_)*=Ooo=======

Kéne még egy kis segítség.

van 3 tábla (képen 1,2 a cikkek, 3,4, csak a cikket + a kategóriákat kapcsolja össze, 5,6 kategóriák)

Van olyan cikk amihez több kategória is tartozik. ezt hogy lehetne megcsinálni.

Nem biztos hogy jól értem, de ha csak annyit szeretnél, hogy egy cikknek több kategóriája legyen, akkor csinálsz egy táblát a cikk id-vel, meg kategória id-vel és kész. Annyiszor veszed fel a kategória id-ket amennyi szükséges.

cikk_id | category_id
1 | 2
1 | 3

[ Szerkesztve ]

"hacsak nem jön a jó tündér break utasítás képében..."

Ezek kész táblák, ebből kéne kinyernem, hogy egy adott cikkhez mely kategóriák tartoznak.

Ehhez kéne egy lekérdezés amivel visszakapom a kategóriákat az adott cikkhez.

Remélem így érthető.

Asszem így jó:

select akármi, ( select cat_title from [ 3. tábla ] where id = ( select entrycategory_id from [ 2. tábla ] where entry_id = [ 1. tábla].id ) ) as kategória from [ 1. tábla ];

[ Szerkesztve ]

"hacsak nem jön a jó tündér break utasítás képében..."

Sajnos ezt a hibaüzenetet kapom :

Query failed: Subquery returns more than 1 row

select kategória from [3. tábla] LEFT JOIN [2. tábla ] ON [3.tábla].id = [2. tábla ].category_id where [2. tábla ].entry_id = ?

"hacsak nem jön a jó tündér break utasítás képében..."

Az volt a javaslat, hogy temp tábla helyett hozzunk létre minden esetben igazi táblákat. Belegondolni is nonszensz...
Megdöbbentő, hogy néha magukat szakértőnek kiadó emberek, cégek mennyire nem értenek az adott témához.
Azt mondták azért jobb a minden esetben fizikai tábla, mert azt jobban lehet optimalizálni. Ez akár igaz is lehetne, node legyen több száz, több ezer fizikai táblánk? Ki fogja ezt karbantartani, átlátni? Hülyék....

Én kérek elnézést!

Gondolom Te valami ilyesmit szeretnél: [link]. Ez elég jó segítség lehet.

Sk8erPeter

Nem ilyet keresek hanem 100%-osan ezt . Köszönöm

Brown ügynök: Neked is köszönöm a fáradozást.

[ Szerkesztve ]

Szeretnék mégegy segítséget kérni igaz most próbálkoztam de valami nem jó.

SELECT url, count(*) as hsz FROM comments group by url limit 0,15
ez a kód megy is ezzel megkapom ugye url szerint csoportosítva a hozzászólások számát.

Viszont nekem ezt még rendeznem kéne. a cikk kiadása szerint.
De sajnos ami szerinte rendeznem kéne az egy másik táblában van.
Még hozzá a cikkek (entries) táblában.

Ez a lekérdezés a cikk többi adatáts szolgáltatja számomra és itt már rendezve, van és hogy ehhez meglegyen a hozzászólások száma is.

SELECT entries.title, , summary, entries.url, startat,
GROUP_CONCAT(entrycategories.title SEPARATOR ', ') categories
FROM entries
LEFT JOIN entries_entrycategories
ON entries.id = entries_entrycategories.entry_id
INNER JOIN entrycategories
ON entries_entrycategories.entrycategory_id = entrycategories.id where entries.active = 1 and startat <= '$date'
GROUP BY entries.title ORDER BY startat DESC LIMIT 0,15

Remélem érthető mit szeretnék.

Ha tudtok valami jó anyagot sql-hez azt is megköszönném.

Elég nagy könnyítés lenne, ha megmutatnád a táblaszerkezeteket. Legalábbis most ennyiből nehéz kitalálni, mi szerint kéne joinolni a `comments` táblát is a jelenlegi query-hez, melyik id-nak kell stimmelni. Persze találgatni lehet, de egyszerűbb lenne, ha a konkrét megoldást tudnánk megmutatni, nem?

Ha pl. phpmyadminban rámész az exportra, mutatja a CREATE TABLE... részt (sql dump), abból már elég jól látható lenne a dolog.

[ Szerkesztve ]

Sk8erPeter

Comments

CREATE TABLE IF NOT EXISTS `comments` (
`id` int(11) unsigned NOT NULL auto_increment,
`url` varchar(255) collate utf8_unicode_ci NOT NULL,
`user_id` int(11) unsigned NOT NULL,
`username` varchar(255) collate utf8_unicode_ci NOT NULL,
`text` text collate utf8_unicode_ci NOT NULL,
`replyto` int(11) unsigned NOT NULL,
`rank` int(11) unsigned NOT NULL,
`created` int(10) unsigned NOT NULL,
`updated` int(10) unsigned NOT NULL,
PRIMARY KEY (`id`),
KEY `rank` (`rank`),
KEY `url` (`url`),
KEY `user_id` (`user_id`)
)

Entries
CREATE TABLE IF NOT EXISTS `entries` (
`id` int(11) unsigned NOT NULL auto_increment,
`file_id` int(11) unsigned NOT NULL,
`user_id` int(11) unsigned NOT NULL,
`startat` int(11) unsigned NOT NULL default '0',
`title` varchar(255) collate utf8_unicode_ci NOT NULL,
`url` varchar(255) collate utf8_unicode_ci NOT NULL,
`summary` text collate utf8_unicode_ci NOT NULL,
`text` text collate utf8_unicode_ci NOT NULL,
`comments` int(11) unsigned NOT NULL default '0',
`sticky` tinyint(2) unsigned NOT NULL default '0',
`comment_enabled` tinyint(2) unsigned NOT NULL default '1',
`active` tinyint(2) unsigned NOT NULL default '1',
`rank` int(11) unsigned NOT NULL,
`updated` int(11) unsigned NOT NULL,
`created` int(11) unsigned NOT NULL,
PRIMARY KEY (`id`),
KEY `file_id` (`file_id`),
KEY `url_2` (`url`),
KEY `rank` (`rank`),
KEY `startat` (`startat`),
KEY `sticky` (`sticky`),
KEY `user_id` (`user_id`),
KEY `title` (`title`),
KEY `comment_enabled` (`comment_enabled`),
KEY `active` (`active`),
KEY `created` (`created`),
KEY `updated` (`updated`)
)

Entries_entrycategories
CREATE TABLE IF NOT EXISTS `entries_entrycategories` (
`entry_id` int(10) unsigned NOT NULL,
`entrycategory_id` int(10) unsigned NOT NULL,
PRIMARY KEY (`entry_id`,`entrycategory_id`),
KEY `fk_wb_entrycategories_has_wb_entries_wb_entries1` (`entry_id`)
)

entrycategories
CREATE TABLE IF NOT EXISTS `entrycategories` (
`id` int(10) unsigned NOT NULL auto_increment,
`lft` int(10) unsigned NOT NULL,
`rgt` int(10) unsigned NOT NULL,
`parent_id` int(10) unsigned NOT NULL,
`scope` int(10) unsigned NOT NULL,
`main` tinyint(2) unsigned NOT NULL,
`showitems` tinyint(2) unsigned NOT NULL default '1',
`file_id` int(10) unsigned NOT NULL,
`title` varchar(250) collate utf8_unicode_ci NOT NULL,
`url` varchar(250) collate utf8_unicode_ci NOT NULL,
`jumpto` varchar(250) collate utf8_unicode_ci NOT NULL,
`active` tinyint(3) unsigned NOT NULL default '1',
`created` int(10) unsigned NOT NULL,
`updated` int(10) unsigned NOT NULL,
PRIMARY KEY (`id`),
KEY `url_2` (`url`),
KEY `lft` (`lft`),
KEY `rgt` (`rgt`),
KEY `parent_id` (`parent_id`),
KEY `active` (`active`),
KEY `created` (`created`),
KEY `file_id` (`file_id`),
KEY `main` (`main`),
KEY `scope` (`scope`),
KEY `showitems` (`showitems`),
KEY `jumpto` (`jumpto`)
)

Szia!

Ahhoz mit szólsz, ha fogod a "Comments" táblára megírt lekérdezésed (url és count(*) mezőkkel), amit az "url" mezőn keresztül összekötsz az "Entries" táblából készített lekérdezéssel (ami csak az "url" és a "created" mezőket tartalmazza", majd tolsz az egészre egy DISTINCT-et?

Valahogy így:

SELECT DISTINCT
comments_allekerdezes.url
,comments_allekerdezes.db
,entries_allekerdezes.created

FROM

(SELECT url
,COUNT(*) as db
FROM comments
GROUP BY url) comments_allekerdezes

,(SELECT url
,created
FROM entries) entries_allekerdezes

WHERE comments_allekerdezes.url = entries_allekerdezes.url

ORDER BY entries_allekerdezes.created

[ Szerkesztve ]

Nekem jó lenne, csak az a gond, hogy semmit nem kapok vissza ebből a lekérdezésből.

Megvan miért nincs választ az url mezőkben levő linkek nem ugyan olyan formában vannak , a comment ben van egy cikk/ az url elött a másikban nincs.

[ Szerkesztve ]

Az lehetséges valahogy , hogy amikor összehasonlítanák két mezőt akkor az egyikenk aza elejét ki képne egészíteni a "cikk/" -el és akkor már lennének ugyan olyan tartalmú mezők.

[ Szerkesztve ]

CONCAT
WHERE CONCAT('cikk/', comments_allekerdezes.url) = entries_allekerdezes.url

Továbbá: összehasonlítanék

[ Szerkesztve ]

- http://pazsitz.hu -

Nem teljesen értem, mit szeretnél kiegészíteni, de a kiegészítés lényegében egy összefűzésnek felel meg, amit vagy a CONCAT paranccsal, vagy a || operátorral tudsz megtenni.

Pl. CONCAT('jóska', 'pista') = 'jóskapista'
vagy
'jóska' || ' és ' || 'pista' = 'jóska és pista'

Eleve azt nem értem, miért URL szerint csoportosítod... Az URL szerinti "összekötéssel" sem értek egyet, nagyon rossz megoldás.
Szerintem az lenne a normális megoldás erre, hogy van mondjuk egy cikked/bejegyzésed, annak pedig van egy id-ja, és egy másik táblában meg az ehhez a cikkhez és id-hoz tartozó kommentek, hozzászólásoko vannak nyilvántartva. A másik, kommenteket tároló táblában tehát tárolod a cikk id-ját is, és ennek segítségével JOIN-olod a két táblát (nem pedig az url mező segítségével; vagy csak simán lekérdezed a cikkhez tartozó kommenteket), így megkapod a cikkhez tartozó kommenteket.
Most a Te comments tábládban nem látok ilyen, a konkrét cikkre vonatkozó id-t, ami jelezné, hogy a kommentek melyik cikkhez tartoznak, az entries táblában viszont látok egy "comments" mezőt. Ennek most nem nagyon értem a szerepét, mert ha ebben felsorolásszerűen vannak a kommentek id-jai, akkor az nagyon rossz megoldás. De lehet, hogy ennek ehhez nincs köze, erről nem írtál, kitalálni meg nehéz.
Viszont ezt az url mezőn keresztüli összekapcsolgatást gyorsan felejtsd el. Az sem világos, hogy ha ennek a két url mezőnek elvileg azonosnak kellene lenni, akkor mi értelme, hogy ebből kettő van... Szerintem átalakításra szorul a táblastruktúrád, vagy most hirtelen csak én nem veszek észre valamit.

Sk8erPeter

Sajnos az adatbázis nem az enyém, amiből dolgozok, nekem csak aza adatokat kell kinyernem belőle. Én sem tartom jó dolognak ezt, de sajnons nincs más lehetőségem, csak olvasási jogom van az adatbázira, abból kell dolgoznom ami rendelkezésemre áll.

Maga az a comment mező semmit nem tartalmaz, én először azt hittem az kapcsolja össze a kommentekel, vagy kommentek számát adja vissza de sajnon nulla az összes érték

Én elfelejteném az UT-en keresztüli összekapcsolást ha lenne más lehetőség de nincs.

Vicc az egész amúgy, 1 hete kérdeztem a fejlesztőktől, tegnap jött rá a választ de arra az időre rájöttem mindenre.

Szerintem az adatbázis ahogy épült az oldal , úgy rakták össze, egy UML diagrammjuk sincsa az adatbázisről, hoyg a kapcsolatokat láthassam. Nem is készült a projekthez ezért vannak szerintem ilyen fejetlenségek benne.

PazsitZ, Apollo17hu: köszönöm a válaszokat.

Ja értem, így már más a helyzet. Akkor végül megoldódott a dolog a CONCAT-tal?

Amúgy szerintem az is gáz, hogy ha már eleve nem adnak a kezedbe egy normális dokumentációt az egészről, akkor legalább használnák ki a kommentelési lehetőséget a táblákhoz és annak egyes mezőihez. Azt sem véletlenül találták ki. Mondjuk ritkább, hogy komplex rendszernél az adatbázison belül kommenteket helyeznének el, de akkor jobb esetben legalább van valami doksi az egészről.

[ Szerkesztve ]

Sk8erPeter

Nem tudja valaki hogyan lehet egy MySQL-ben összefűzni két nvarchar típusú értéket.

Mire megírtam a kérdést addigra megtaláltam a választ is rá.

Concat('Egyik szöveg','Másik szöveg')

Ahogy az angoltanárom mondta egyetemen: "You shoud go to the elementary school" +

Na meg ahogy látom itt is éppen ez a téma, bocsánat a redundanciáért.

[ Szerkesztve ]

Másik kérdés valaki tudja mi a különbség a

like valami%'
és a
like 'valami%'

között
MySQL-ben dolgozom jelenleg és semmi nem úgy van mind a nagyoknál . Oracle és MSSQL-ben vágom.

[ Szerkesztve ]

A felső szintaktikailag hibás. Az alsó pedig: "ahol a szó eleje megegyezik a valami-vel"

"hacsak nem jön a jó tündér break utasítás képében..."

okés akkor újabb kérdés.
'valami'
"valami"
Között mi a különbség?

Mi a különbség a macskaköröm és az aposztróf között?

"hacsak nem jön a jó tündér break utasítás képében..."

Köszönöm.
MySQL-nek szinte mindegy.
Oracle-ben és MSSQL-ben ez nincs így.

"Stick to using single quotes."
Mondjuk én MySQL-ben pont a dupla idézőjelekhez ragaszkodom a query-knél a PHP-s kódjaimban. Ennek egyszerű a magyarázata, PHP-ben ha duplaidézőjelbe teszek egy adott stringet - pl. az egész query-t, amit majd le akarok futtatni -, akkor a PHP megpróbálja megkeresni a benne lévő esetleg behelyettesítendő változókat, ez meg lassít. Ezért az egész stringet (magát a query-t) aposztrófok közé rakom, és hogy ne kelljen escape-elni mindig az ezenbelül lévő aposztrófokat, inkább macskakörmöt használok. Ha működik, és nem számít hibásnak, a tököm se fog szenvedni az escape-elgetéssel.

(Persze más adatbázisnál akkor marad az escape-elés, vagy az egész string macskakörmök közé rakása.)

[ Szerkesztve ]

Sk8erPeter

Sziasztok!

Kellene nekem egy ki segítség. Felraktam a web-re a webspellt viszont a video rész nem működik egészen pontosan ez írja ki:
# Query failed: errorno=1146
# error=Table 'teamdestiny555.ws_K2E_videos_settings' doesn't exist
# query=SELECT * FROM ws_K2E_videos_settings

ez ugyebár azt jelenti, hogy nincs ilyen tábla az sql file-ban ami a serveren van viszont ahhoz hogy legyen be kéne írni de nem tudjuk a cellákat szóval kellene egy működő és abból átírni vagy azt felrakni ehelyett ha van esetleg valakinek kérem dobja át nekem vagy ha valaki tudja milyen sorok híányzonak beírom hátha működik vele.

előre is nagyon köszönöm mindenkinek aki segít

üdv.: Thumb

A lepke egy olyan rovar, amely a helikopterek családjából származik.

És ezt végigcsináltad? Különösképpen az 5-ös 6-os pontokra:

http://www.webspell.org/index.php?site=faq&action=faq&faqID=16

Hibát írt ki közben?

Amúgy mire jó ez a webspell CMS? Miben jobb mint a hagyományos CMS-ek?

Én kérek elnézést!

Szia!

Elméletileg igen de voltak problémák! Ez lehet egyébként baj forrása?

eddig így néz ki szerintem ezek okésak benne csak olyan mintha ezt kifelejtette volna az sql-ből ez

[ Szerkesztve ]

A lepke egy olyan rovar, amely a helikopterek családjából származik.