Milyen különbségeket sql-mysql lekérdezés szintaxist Firebird
Ha nem akarjuk, hogy az első - nem kap ki egyáltalán!
Nem emlékszem, régen dolgozott FB. De minden, hogy tudom, az SQL-adatbázisok - MySQL az egyetlen olyan adatbázis azon, hogy feltalálta az „Egyéni SQL Blackjack és méret LIMIT'a.”.
Itt megtalálható az idézet, mintegy FireBird 1.5:
Firebird teljes mértékben támogatja az SQL-92 Entry Level 1 és megvalósítja a legtöbb SQL-99 szabvány c néhány nagyon hasznos kiegészítéseket. Ez magában foglalja expressziós DML / DDL, társulásai szintaxis FULL / balra / jobbra [KÜLSŐ] REGISZTRÁCIÓ, expressziós UNION, DISTINCT, subqueries (IN, van), beépített funkciókat (AVG, SUM, MIN, MAX, COALESCE, CASE.), Integrity korlátok (elsődleges kulcsot, EGYEDI, iDEGEN KULCS), és valamennyi közös SQL adattípusok.
A fentiek írtak, valamint azt Postgres is végrehajtja a legtöbb ilyen szabványok, lekérdezéseket kell dolgozni, és FireBird és Postgres, gyakorlatilag nem változott. Ezen kívül, mint amennyire emlékszem, a FireBird (legalább volt változatban 1,5 és 2x), valamint a „szekvencia” kifejezések a Postgres. ehelyett MySQL'evskogo AUTOINCREMENT'a.
Összefoglalva, azt akarom mondani, hogy meg kell keresni nem az, amit FireBird'a szintaxis eltér MySQL'evskogo és milyen MySQL'evsky-SQL eltér SQL szabványoknak.
Igen, nincs auto-növekmény, valamint a Postgres, de ez nem kérés, és maga az adatbázis architektúra valószínű.
Határ 1, 2 - MySQL, van írva a végén a lekérdezés
OFFSET határ 2 1 - PostgreSQL, írásos végén a lekérdezés
ELSŐ SKIP 1 2 - Tűzmadár, meg van írva, miután a SELECT
Ez nagyon kellemetlen, ha nem lapszámozásának oldalak, például. De ez egy kis töredéke a baj, mert az ilyen „zsemle” tényleg sok. Vegyük például összefűzés helyett GROUP_CONCAT () van egy funkciója LIST (), amely nem rendelkezik annyi lehetőség, mint GROUP_CONCAT (), például, nincs mód arra, hogy a sorrendben alsztringek kuplung - ez lesz a bemenet egy rendezett folyam, ami azt jelenti, akkor kell használni egy másik funkció.