Kezdőlap › Fórumok › Programozás › SQL programozás
- This topic has 37 hozzászólás, 9 résztvevő, and was last updated 19 years, 4 months telt el by
kl223.
-
SzerzőBejegyzés
-
2005-11-06-19:18 #2012951gUHU wrote:ha adsz egy specifikációt meg tudom mondani
legyen egy sima reggelõs üzenõfal… user és post táblával;
2005-11-06-21:49 #2012952xcut wrote:és a view azért jó, mert rövidebb a querysrting -> rövidebb idõ a kommunikáció…A view azért jó, mert ‘elõre eltárolhatod a lekérdezési feltételt’, így tényleg rövidebb lehet a querysrting.
Viszont nem biztos, hogy a kommunikáció rövidebb. Amúgy a jobb Db kezelõk a szerveren hajtják végre, amit kérsz, és csak az eredményt nyomják át a hálózaton, így tök mindegy a kommunikáció szempontjából, hogy mekkora SQL paranccsal kérsz, az eredménye az, ami számít.
Ha jól tudom az MS ACCESS viszont pont nem így mûködik, ha egy helyi acces progival használsz egy másik gépen lévõ access db-t, akkor minden adatot áthoz elõbb és helyileg hajtja végre az SQL parancsot. Vagy csak rossz volt a konfig ott, ahol ettõl kaptam szívgörcsöt majdnem, amikor rájöttünk miért rohangálnak gigabájtok a hálózaton :).2005-11-06-22:19 #2012953Leslieman wrote:xcut wrote:és a view azért jó, mert rövidebb a querysrting -> rövidebb idõ a kommunikáció…A view azért jó, mert ‘elõre eltárolhatod a lekérdezési feltételt’, így tényleg rövidebb lehet a querysrting.
Viszont nem biztos, hogy a kommunikáció rövidebb. Amúgy a jobb Db kezelõk a szerveren hajtják végre, amit kérsz, és csak az eredményt nyomják át a hálózaton, így tök mindegy a kommunikáció szempontjából, hogy mekkora SQL paranccsal kérsz, az eredménye az, ami számít.
Ha jól tudom az MS ACCESS viszont pont nem így mûködik, ha egy helyi acces progival használsz egy másik gépen lévõ access db-t, akkor minden adatot áthoz elõbb és helyileg hajtja végre az SQL parancsot. Vagy csak rossz volt a konfig ott, ahol ettõl kaptam szívgörcsöt majdnem, amikor rájöttünk miért rohangálnak gigabájtok a hálózaton :).Mondjuk egy ilyen esetben (haver kódja, adta példának):
Code:CREATE OR REPLACE VIEW „public”.”vforum_group” (
id,
name,
desc,
type,
topics,
posts,
lastpost,
lastuserid,
lastusernick)
AS
SELECT forum_group.id, forum_group.name, forum_group.”desc”, forum_group.”type”, (
SELECT count(*) AS count
FROM forum_topic
WHERE (forum_topic.parent = forum_group.id)
) AS topics, (
SELECT count(*) AS count
FROM forum_post
WHERE (forum_post.parent IN (
SELECT forum_topic.id
FROM forum_topic
WHERE (forum_topic.parent = forum_group.id)
))
) AS posts, (
SELECT date_part(‘epoch’::text, max(forum_post.date)) AS date_part
FROM forum_post
WHERE (forum_post.parent IN (
SELECT forum_topic.id
FROM forum_topic
WHERE (forum_topic.parent = forum_group.id)
))
) AS lastpost, (
SELECT „user”.id
FROM „user”
WHERE („user”.id = (
SELECT forum_post.writer
FROM forum_post
WHERE (forum_post.parent IN (
SELECT forum_topic.id
FROM forum_topic
WHERE (forum_topic.parent = forum_group.id)
))
ORDER BY forum_post.date DESC
LIMIT 1
))
) AS lastuserid, (
SELECT „user”.nick
FROM „user”
WHERE („user”.id = (
SELECT forum_post.writer
FROM forum_post
WHERE (forum_post.parent IN (
SELECT forum_topic.id
FROM forum_topic
WHERE (forum_topic.parent = forum_group.id)
))
ORDER BY forum_post.date DESC
LIMIT 1
))
) AS lastusernick
FROM forum_group;Csak egyszerûbb (és kisebb ^^) beírni azt, hogy: `SELECT * FROM „public”.”vforum_group”;`, mint elküldeni ezt a kilóméteres query-t ^^
Ilyen MySQL környezetben is simán elõfordulhat, és ott marad a kilóméteres subquery…2005-11-12-14:42 #2012954hi
megterveztem az adatbázisomat, már készen is van külön-külön, teszteltem is, jól mûködik[MS Access], és most szeretném ezt átvinni MySQL-be. Nem nagy ügy PHPMyAdminnal megcsinálni a táblákat, de még SQL-lel sem, ámde van egy dolog, amit nem tudom megoldani. Van két táblám, amik között 1:N kapcsolat van. Ezt hogyan tudom a MySQL-ben megoldani?
2005-11-12-15:30 #2012955str2etboy wrote:himegterveztem az adatbázisomat, már készen is van külön-külön, teszteltem is, jól mûködik[MS Access], és most szeretném ezt átvinni MySQL-be. Nem nagy ügy PHPMyAdminnal megcsinálni a táblákat, de még SQL-lel sem, ámde van egy dolog, amit nem tudom megoldani. Van két táblám, amik között 1:N kapcsolat van. Ezt hogyan tudom a MySQL-ben megoldani?
a valós helyzet jobb lenne, mint a szakszöveg. Akkor érteném is 🙂
2005-11-12-16:23 #2012956egy a többhöz kapcsolatot szeretnék létrehozni. pl egy id-hez több másik táblában található tartlom is tartozhat.
tábla1
tábla2
id1id2
ertek1ertek2a tábla 1bõl az ertek1-hez a tábla2 id2-t szeretném hozzárendelni egy a többhöz kapcsolattal… hogyan lehet SQL-lel megcsinálni?
2005-11-12-19:30 #2012957Fordítsuk meg a dolgot!
2005-11-13-11:15 #2012958Ha standard SQL kódot csináltál, akkor a mysql valószínû nem fogja megenni…
str2etboy: ha rám hallgatsz, akkor hagyod a mysql-t, és egybõl postgres-be kezdesz… tudom, sokkal nehezebb, de ha ráérzel, akkor áldani fogod az eszedet, hogy ebbe kezdtél ^^ ajánlott olvasmány az elõzõ oldalon linkelt BME-s doksi… kb-re az egészet érdemes elolvasni, csak a koordinátatárolást nem feltétlen…
2005-11-18-18:06 #2012959Leslieman wrote:Fordítsuk meg a dolgot!2005-11-18-18:47 #2012960A PostgreSQL valóban sokkal többet tud, mint a mysql. Sokkal komolyabb rendszernek számít, és ezzel együtt nehezebb is megtanulni.
Egyébként úgy nagyjából az általa használt SQL dialektus kompatibilis a MySQL-éval, csak nyilván itt sokkal több elem van, mivel a szerver maga többet tud.
Leginkább úgy mondanám, hogy ami fut mysql-ben, az valószínûleg max minimális változtatásokkal futni fog postgresben is. Visszafelé már nem biztos.Ennek ellenére – ez egyébként örök vita tárgya köztem és xcut között – szvsz ha nem csak magadnak fejlesztesz, érdemes azért a mysql-kompatibilitást fenntartani, mivel a neten a free webszerverek döntõ hányadán még csak mysql fut, postgres nem.
De persze ha a munkád nem akarod kiadni, hanem mondjuk privát szervereken szeretnéd használni, akkor ez mind1.Hogy hogyan lehet a mysql-lel kompatibilis maradni, de egyben a postgres újdonságait kihasználni?
-
SzerzőBejegyzés
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz