Rada při návrhu db tabulek

Re:Rada při návrhu db tabulek
« Odpověď #150 kdy: 28. 06. 2021, 09:40:22 »

Já bych se v tomhle případě Mirka zastal.

Silhavy neni zadny developer, ani backend ani frontend, vy podle vseho take ne.


Re:Rada při návrhu db tabulek
« Odpověď #151 kdy: 28. 06. 2021, 09:46:27 »
Tak samozřejmě, takovou trivku jsem na mysli neměl.

a co jste mel na mysli? Kdy se podle vas pouziva ORM pro dotazovani v cyklu?

PanVP

Re:Rada při návrhu db tabulek
« Odpověď #152 kdy: 28. 06. 2021, 10:20:57 »
Silhavy neni zadny developer, ani backend ani frontend, vy podle vseho take ne.

Já jsem letadlo :-D páne Hackere  ;D 8)

Re:Rada při návrhu db tabulek
« Odpověď #153 kdy: 28. 06. 2021, 10:51:14 »
Tak samozřejmě, takovou trivku jsem na mysli neměl.

a co jste mel na mysli? Kdy se podle vas pouziva ORM pro dotazovani v cyklu?

exporty, generovani analytickych reportu, biling,  fraud detection, ...

PanVP

Re:Rada při návrhu db tabulek
« Odpověď #154 kdy: 28. 06. 2021, 11:07:37 »
fraud detection, ...

Můžete rozvést vzorovou implementaci? Pokud bych provedl úspěšný SQL injection, tak mi to nepomůže ne? Já v jedné aplikaci transakce hashuji.

Doplněni: Je skvělé, že tu diskutujete. Ne každý někdy viděl implementovaný fraud detection.
« Poslední změna: 28. 06. 2021, 11:13:19 od PanVP »


Re:Rada při návrhu db tabulek
« Odpověď #155 kdy: 28. 06. 2021, 11:20:45 »
fraud detection, ...

Můžete rozvést vzorovou implementaci? Pokud bych provedl úspěšný SQL injection, tak mi to nepomůže ne? Já v jedné aplikaci transakce hashuji.

Tady nerozumím otázce - fraud detection primárně neslouží k detekci SQL injection, i když by to asi mohlo detekovat úspěšný průnik (analýzou auditu). Co myslíte pod "hashováním transakcí" ? Ochranou proti SQL injection je důsledná a správná sanitizace všech parametrů dotazů, případně striktní používání prepared statements nebo parametrized statements. Pak je další kapitola minimalizace impaktu kompromitace účtu - ať zaheshováním citlivých údajů nebo používáním standardních security fíčur databáze - víc uživatelů, přístupová práva, maskování hodnot, ..

Re:Rada při návrhu db tabulek
« Odpověď #156 kdy: 28. 06. 2021, 11:48:58 »
Doplněni: Je skvělé, že tu diskutujete. Ne každý někdy viděl implementovaný fraud detection.

Takových systémů bude mraky - co jsem se bavil s lidma, kteří detekce anomálií používají Postgres, tak existuje detekce komunikace na síti, detekce pohybu osob po budovách, automatická analýza databázového auditu, .. dokonce v novějším ANSI/SQL je pro to funkce - analýza vzorů změn

https://fosdem.org/2021/schedule/event/postgresql_postgres_and_the_artificial_intelligence_landscape/

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Rada při návrhu db tabulek
« Odpověď #157 kdy: 28. 06. 2021, 12:07:26 »
300 dotazů na jeden refresh stránky :o  :o :o
WTF (?)
Bavíme se o jedné jediné běžné webové stránce? :o
Tři sta dotazů :o
Jako vážně?
Ale to uvádíte jako příklad enormní ouchylnosti ne?
Běžné je klidně 1500. Pavel byl ještě opatrný.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Rada při návrhu db tabulek
« Odpověď #158 kdy: 28. 06. 2021, 13:32:44 »
Rozhovor se tu krapet zvrhl v několik falešných premis:

- ORM není o tom, nedostat se nebo schovat SQL. Když už něco schovávat, tak to je relační algebra. Ale SQL nikomu nevadí.
- To, že potřebuju specializovaný dotaz, kde dělám hroznou magii neznamená, že nesmím použít ORM. Tím spíše, když specializovaný dotaz je sotva procento všeho.
- To, že někdo zprasil ORM tak, že z toho Pavel málem omdlel neznamená, že napsat si "lehkou obálku" by dopadlo lépe.
- Napsat si "lehkou obálku" nebude automaticky výhodnější.
- Narvat všechno do DB je volená strategie, která nejde přímo proti ORM.
« Poslední změna: 28. 06. 2021, 13:34:36 od BoneFlute »

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #159 kdy: 28. 06. 2021, 16:04:30 »
Rozhovor se tu krapet zvrhl v několik falešných premis:

- ORM není o tom, nedostat se nebo schovat SQL. Když už něco schovávat, tak to je relační algebra. Ale SQL nikomu nevadí.
- To, že potřebuju specializovaný dotaz, kde dělám hroznou magii neznamená, že nesmím použít ORM. Tím spíše, když specializovaný dotaz je sotva procento všeho.
- To, že někdo zprasil ORM tak, že z toho Pavel málem omdlel neznamená, že napsat si "lehkou obálku" by dopadlo lépe.
- Napsat si "lehkou obálku" nebude automaticky výhodnější.
- Narvat všechno do DB je volená strategie, která nejde přímo proti ORM.

Takže žádná z uvedených falešných premis neplatí? Jsi tedy pro "lehké obálky", které budou automaticky výhodnější?

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #160 kdy: 29. 06. 2021, 12:23:58 »
Jak to tady čtu, tak se mi zdá, že pojem ORM je přetížený. Může mít podle různých diskutujících dva dosti odlišné významy:

1) "Full ORM" - něco, co umožní existující "programming language" objekty uložit transparentně do databáze. V tomto případě je bussines logika v aplikaci, DB je storage.

2) "query builder" - něco, co umí "databázové objekty" nějakým způsobem "hezky" zpřístupnit v aplikaci. Bussines logika je tady v DB

To jsou dva naprosto odlišné přístupy, ač základ "ORM" je u nich stejný: bijekce mezi "objekty v DB" a v aplikační vrstvě. A každý má své problémy.

U 1 jsou vešekré problémy s tím, že pokud nestačí výkon ORM a dělají se např. dávkové updaty, obchází se bussines logika. 2 je použitelné, ale zas logikou v DB spousta lidí neumí pracovat a tedy je to finančně drahé (alespoň pro některé typy projektů).

Další věc je, že málokdy je to řešení čistě 1 nebo čistě 2. To právě vede k tomu směšování význam těch dvou povahou dosti odlišných ORM. A je pravda, že to částečně řeší problémy zmíněné výše, ale vzniklá schizofrenie je snad ještě větší problém: v jednu chvíli člověk tvrdě narazí na to, že nejde udělat tlustá čára mezi logikou v APP a v DB - a z toho plyne nemožnost něco dělat efektivně, vyšší riziko chyb atd. atd.

Re:Rada při návrhu db tabulek
« Odpověď #161 kdy: 29. 06. 2021, 16:45:54 »
Jak to tady čtu, tak se mi zdá, že pojem ORM je přetížený. Může mít podle různých diskutujících dva dosti odlišné významy:

1) "Full ORM" - něco, co umožní existující "programming language" objekty uložit transparentně do databáze. V tomto případě je bussines logika v aplikaci, DB je storage.

2) "query builder" - něco, co umí "databázové objekty" nějakým způsobem "hezky" zpřístupnit v aplikaci. Bussines logika je tady v DB

Mě to dělení přijde umělé. U 1 mohu mít taky dost logiky v DB a používat custom SQL dotazy, případ 2 zase může přebírat kompetence z full-orm. Je tam mezi oběma přístupy plynulý přechod (doby kdy byl jen iBatis a Hibernate jsou pryč).

Spíš mi přijde podstatné zda a jak orm řeší persistenci objektového grafu, tj. uložení všech vnořených entit a dále jak řeší persistentní session (attached vs. detached instance), jak flexibilně umí mapovat objekty, zda má nějaké event api, zda a jak lze entity serializovat mimo databázi, zda mohu namapovat entity, ke kterým nemám zdrojový kód apod. To rozhoduje mnohem víc a použitelnosti, rychlosti vývoje a v důsledcích tedy i o výkonu aplikace.

Re:Rada při návrhu db tabulek
« Odpověď #162 kdy: 29. 06. 2021, 23:45:44 »
moderni ORM je v querybuilder + definice entit obsahujici informace navic oproti samotne definici tabulek v databazi, ktere vyuziva jednak querybuilder k snadnejsimu generovani dotazu bez zadavani explicitnich detailu. Ale muze je vyuzivat i aplikace pro generovani API, formularu atd.

samotny nazev ORM je alespon v dynamickych jazycich trochu zavadejici, tam je mapovani sql entit na obekty trivialita, kterou muze delat jakakoliv db knihovna.

tvrzeni, ze kdo zna SQL nepotrebuje ORM, je stejne hloupe jako tvrzeni, ze kdo zna assembler nepotrebuje vyssi jazyky.

Re:Rada při návrhu db tabulek
« Odpověď #163 kdy: 30. 06. 2021, 00:00:24 »
- ORM není o tom, nedostat se nebo schovat SQL.

presne, ORM je o efektivni praci s SQL.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #164 kdy: 30. 06. 2021, 01:10:28 »
Citace
V 1 mohu mít taky dost logiky v DB a používat custom SQL dotazy,
To jde a zpravidla se to tak dělá. Ale to má své velké problémy. Co když chci udělat jako "custom SQL dotaz" update dané vlastnosti, která ovšem je "ztrigerovaná" nikoli v DB, ale v APP? Nebo co když chci jen udělat custom select podle dané vlastnosti, ale ta je ve skutečnosti na APP vrstvě nějak předefinována?

V případě malého projektu, kde se lidé "osobně domluví co bude kde", tak to jde nějak udržet. Ale s  růstem projektu se je podle mne třeba dohodnout, na které úrovni funguje bussines logika - jestli na APP nebo na DB vrstvě, a respektovat to. Lezení pod tuto dohodnutou úroveň je pak "ugly hack". Tzn. jakmile mám nějakou část logiky v APP, tak bych neměl jen tak "mírnix týrnix" lézt bokem do databáze.

Ne, že by takovou app (kde se bokem leze) nešlo "ukočírovat" - jde to, a asi nemálo lidí to tak dělá. Ale s příbývající komplexitou se pak člověk nevyhne dublování funkcionality na APP a na DB vrstvě - a i s tím spojenými chybami, když se ty implementace "rozjedou" (anebo prostě nejsou napsány 100% shodně).
« Poslední změna: 30. 06. 2021, 01:15:57 od Logik »