Keresek egy olyan db engine-t, ami:
-SQL/SQL-szeru nyelvvel query-zheto
-Tudja a relacios adatbazisok common feature setjet, kiveve:
--Primary key csak egyetlen oszlop lehet es az is az autoincrement/serial bigint
--Foreign key nem lehet primary key-ben
--es ugye ennek megfeleloen elindult az optimalizalasa ezen megszoritasok menten, ahogy azt nem (teljesen) relacios adatbazisoknal (leanykori neven NoSQL) mar megszokhattuk.
Az se baj, ha ez egy (nemtrivialis) MySQL/PostgreSQL fork, vagy akar egy db engine a MySQL-hez peldaul (ahogy pl. a Facebook is forkolt maganak masik MySQL-t feltetelzve, hogy igen ritkan fog DELETE-t futtatni, es annak karara gyorsabb lehet sok mas muvelet). De az mar igen, ha csak egy config fajlt/plsql scriptet latok, es nem indult el az engine abba az iranyba, hogy kihasznalja annak az elonyet, hogy mindig van integer primary key. Annyi erovel felhuzhatok egy Postgres-t, es megmondhatom, hogy "holnaptol ez a szabaly".
Kerdes, van-e ez utobbinal (Mysql/Postgres + "jatekszabalyok") elegansabb es optimalizaltabb megoldas?
- 1296 megtekintés
Hozzászólások
Elgepeltem:
*--foreign key-ben csak masik tabla primary key-e lehet
Nem tudom editalni
- A hozzászóláshoz be kell jelentkezni
Nem értettem mit akarsz. Így már ok.
(rejtett sub)
- A hozzászóláshoz be kell jelentkezni
Egy gépen egy példányban kell futnia vagy mondjuk legyen distributed?
- A hozzászóláshoz be kell jelentkezni
Legalabb annyira replikaljon jol, mint a legismertebb SQL engine-ek. (Majdnem)RDBMS leven Unique key-eket is kell tamogatnia, es azert abban tobb limitacio felmerul, foleg ha irni is kell. Szoval nem ez a fo szempont, de ha jobban skalazodik horizontalisan, az termeszetesen elony.
- A hozzászóláshoz be kell jelentkezni
Meglepne ha találnál olyat engine-t ami számottevően jobb a sima SQL szervereknél, tekintve hogy a követelmények eléggé tipikusak ahhoz, hogy az sima SQL szervereket is ezekre optimalizálják...
- A hozzászóláshoz be kell jelentkezni
Ez az en tapasztalatom is amugy, hogy azok is igy hasznalva gyorsabbak es konnyebben optimalizalhatoak. Kerdesem, hogy tud-e szignifikansan gyorsabb lenni, ha nem lehet nemigy hasznalni. Es ha lehet, valaki dolgozott-e ezen?
- A hozzászóláshoz be kell jelentkezni
Félve kérdezem: miért kell neked ilyen? Miért nem jó egy már meglévő megoldás? Tesztelted őket? Mi lett az eredmény, hogy ez a kérdés felmerült? Vagy egyszerűen csak "túl sokat tudnak, elég lenne nekem egy ilyen" a hozzáállás? Komolyan kérdezem, mert érdekel use case.
- A hozzászóláshoz be kell jelentkezni
Leginkabb kivancsisag. Erosen elmeleti.
Meglevo SQL motorok is igy hasznalva teljesitettek korabbi tapasztalataim soran a legjobban, es sajat szememmel lattam, hogy omlanak ossze partizmillio sornal a nem ily modon tervezett tablak filterei egy nehany tablas joinnal (igen, voltak indexek). Aztan ehhez jon hozza, hogy egy UPDATE, vagy egy DELETE is rovidebb ideig lockolja a tablat, ha csak primary key listat adunk at neki.
Es ha mar egyszer igy a leggyorsabb, volt-e barki, aki gondolt mar arra, hogy csak ezek lehessenek a create table-ben, es ha volt, nyert-e mas optimalizalhatosagot (db engine szintjen) ezeken a megszoritasokon? (Akar meressel, akar "nekem kell merni" alapon).
- A hozzászóláshoz be kell jelentkezni