Az orosz nevek használata az sql-lekérdezés szövegében
Az orosz nevek használata az SQL lekérdezés szövegében.
Kérlek a mesterek segítségét.
Talán a probléma a legjobb megoldás,
Szeretném tudni a változatom helyességét.
Számos kérés van (például a rövidített változatot eredményezem):
SELECT
# xA0; Subject.Familiya mint [Vezetéknév],
# xA0; Hely. Tipp mint [Ország típusa]
FROM
# xA0; Subject, Location
WHERE
# xA0; Subject.S_L_id = Hely.L_id
Kiderül, hogy az orosz mezőnevek ugyanabban a lekérdezésekben vannak tárolva
mint álnevek.
Mindezeket a kéréseket önmaguk használják, de emellett
mindegyiket egymásba ágyazott lekérdezésekként használják, például:
válasszon a. [Ország típus], számláló (*) [szám]
tól (
# xA0; SELECT
# xA0; # xA0; Subject.Familiya mint [Vezetéknév],
# xA0; # xA0; Hely. Tipp mint [Ország típusa]
# xA0; FROM
# xA0; # xA0; Subject, Location
# xA0 WHERE
# xA0; # xA0; Subject.S_L_id = Hely.L_id
) a
csoportja # xA0; a. [Ország típus]
Amit nem szeretem erről, az a lekérdező szöveg
Orosz alias a. [Ország típus].
Szerintem ez nem nagyon szép.
Léteznek problémák a többi számítógépen?
Másrészt, csak egy sor soros sorozatot tartogat a mező címkével
kényelmetlen. Tartsa meg a kérések 2 listáját, ahol mindegyik pár 95% -os ismétlődik
túl kényelmetlen.
Most, ha több álnevet adhat meg egy mezőbe vagy hozzáférhet hozzá
eredeti nevével.
A kérdés tehát: helyes-e az orosz nevek használata az SQL lekérdezés szövegében?
DBMS hozzáférés, ADO.
Helyes az orosz nevek használata az SQL lekérdezés szövegében
Mindez a DBMS-től függ. Ha a DBMS támogatja a Unicode vagy az orosz kódolást, akkor teljesen helyes.
> helyes-e az orosz nevek használata az SQL-
> kérni?
Nem, nem az.
Nekem úgy tűnik, hogy Access számára ez normális.
Nem használom. Szeretném megadni az orosz nevet a mezőleíróban (displaylabel). A kérelmek rövidebbek és érthetőbbek.
> SELECT
> # xA0; Subject.Familiya as [Vezetéknév],
> # xA0; Hely. Tipp: [Ország típusa]
> FROM
> # xA0; Tárgy, Hely
> WHERE
> # xA0; Subject.S_L_id = Hely.L_id
Nem jobb?
SELECT s.Familiya, Tipp
FROM Tárgy s
IHHER JOIN Helyszín l ON s.S_L_id = l.L_id
Tehát az orosz nevek az SQL-en kívül tárolódnak?
> Az orosz nevek csak a program felületén használhatók.
És sehol máshol!
Ponimyau.
Azt is jelenti, hogy a mezőnevek tárolására egy tömböt is használhatunk?
> Nem jobb?
> SELECT s.Familiya, I. Tipp
> FROM Tárgy s
> IHHER JOIN Helyszín l ON s.S_L_id = l.L_id
Egyetértek, jobb, nem tudom újrafogalmazni, szokás.
> Nem használom. Szeretném megadni az orosz nevet a leíróban
> mezők (displaylabel).
Tehát nem működik ebben a feladatban,
mert Ugyanaz az adatkészlet kezelni fogja a különböző kéréseket, pl.
a TField létrehozásának ideje nem lehetséges, és még a sebzési idő is valószínűleg nem lesz lemosva?
És csak ezután, a fájladatok olvasása után természetesen hozzárendeli a displaylabel értékeket a tömbhöz.
> Aha, értem. És nem hallottál a Fields-ról a TDataSet-ről?
:)) hallottam
> Igen. Igen, valószínűleg. Igen, de nagyon hülye. Igen, de jobb
> Nekünk ":)
> Ó, hány aranyérmet oroszul a Delphi!
Jobb, ha a tervezésekor változtatsz időben, mint később
lapát megfelelően működik.
Köszönöm, reggel elkezdek felújítani (jó, amíg egy kicsit).
> Egyébként. Tudja-e valaki, hogy olyan nyelven van, amelynek van egy levele?
> a 255-es kódra?
Nem tudom mit? Kód mint kód ..
>> By the way. Tudja-e valaki, hogy olyan nyelven van, amelynek van egy levele?
>> a 255-es kódon?
>
> Nem tudom mit? Kód mint kód ..
>
A Delphi egyes verziói esetében az ilyen kód jelenléte a program szövegében egy "vörös rongy"! Pontosabban a program szövegének elején. Pontosabban, nem emlékszem. (Sclerosis, átkozott.
> Igen, és a sebzési idő is, valószínűleg elmosódott nem?
Természetesen nem. maguk is létrejönnek. mivel az orosz neveket nevezném a későbbiekben (amikor már létrejöttek), és ez az.
Srácok, valószínűleg továbbra is 8.3-as formátumban hívják a fájlokat? Igen?
>> helyes az orosz nevek használata az SQL-
>> kérés?
Nem minden olyan egyszerű. Két helyzetet adok neked
1) Valószínűleg mindenkinek van egy gyűjteménye a lekérdezésekről - "segédprogramok", mondja a munkamenet statisztikáit, az I / O dinamikát és a rendszer tábláinak egyéb adatait. Végrehajtom őket az SQL * Plus-ból, és néha az eredményt meg kell küldeni valakinek. A HTML formázott kimenet egy parancs és 0,1 másodperc. időben. A mezők átnevezése (és gyakran az összes feldolgozás eredménye) hosszú idő, és mindenkor meg kell csinálni. Ezért minden eredmény előre az orosz psenvdonimami
2) Sok aktuális jelentést tárolnak a tárolt eljárások, amelyek visszaadják a kurzort. Két tucat típusú kliens alkalmazásokat használnak - és webes szolgáltatásokat (többek között mások), vastag ügyfeleket és vékony HTML-ügyfeleket, sőt a FIG tudja, ki. Mindegyikben meg kell írni a fejlécek átalakítását (és később változtatni) felesleges problémák. Hasonlóképpen, a kurzor a mezők orosz címsorával megy. Úgy működik, mint egy óra. # xA0; Alternatív megoldások ismertek nekem, de ez a módszer teljesen működőképes és joggal rendelkezik az élethez, még az IMHO-hoz sem
> Tud-e valaki olyan nyelvet, amelynek levele a 255-es kódba esett?
Gyakran. Nyissa meg a szimbólum táblázatot a Windows rendszerben és nézze meg.
> Sergey Masloff (06/05/07 10:45) [19]
Mindez indokolt. De csak az erőforrás-igényes módosítások indokolják. Mert eredetileg nem gondolták. Az alapvető tervezési pontok - tárolás (a tárolás módja a nevek egy részében) és a kijelző összekeveredtek.
És nem azt mondom, hogy ez a módszer nem életképes vagy nem kivitelezhető. Egyes esetekben.
Csak azt mondom, hogy a nemzeti szimbólumok az SQL-ben nyelvi konstrukciók, tokenek stb. és hasonlók. TILOS.
Igen. hány ember annyi véleménnyel rendelkezik.
teljesen leütött.
Minden, javítva.
Köszönöm mindenkinek.