Ako formátujete SQL queries v PHP? rubrika: Programování: PHP

1 robo.balasko
položil/-a 13.8.2013

Aký je najlepší spôsob formátovania SQL v PHP súboroch?

Varianta 1:
$sql = "INSERT INTO tabulka (column, column, column,...) VALUES (hodnota, hodnota, hodnota,...) WHERE ...

Varianta 2:
$sql = "INSERT INTO tabulka";
$sql .= "(column, column, column, ...)";
$sql .= "VALUES";
$sql .= "(hodnota, hodnota, hodnota, ...)";

Varianta 3:

  • nejaký váš lepší spôsob?
odkaz
5 JanVoracek
odpověděl/-a 13.8.2013

Varianta 3: Nepsat SQL v PHP souborech.

Komentáře

  • siq : A kam ich teda pisat? — 13.8.2013
  • JanVoracek : Nikam. Použit abstrakci, která je na pozadí dynamicky skládá. Až na opravdu specifické případy není potřeba psát ručně SQL. — 13.8.2013
  • jaroslav.kubicek : hodnocení -2? WTF?! To myslíte vážně? Tajně doufám, že po složení takového dotazu přijde alespoň $pdo->bindParam ... Sakra lidi, když už, tak alespoň: 1) http://www.doctrine-project.org/ nebo 2) http://dibiphp.com/ 3) http://www.notorm.com/ — 14.8.2013
  • siq : Niekedy si clovek to SQLko potrebuje napisat rucne. Abstrakcia moze riesit 99.99% pripadov pouzitia, ale clovek sa moze dostat k problemu ktory abstrakcia vyriesit nedokaze. Odhliadnuc od toho ze rucne pisane query su o nieco malo rychlejsie. — 14.8.2013
  • jaroslav.kubicek : pokud se takový případ vynoří, tak často stojí za zvážení, zda to, o co se snažím, by nebylo vhodné vyjádřit funkcí/pohledem přímo v db — 14.8.2013
  • siq : To ano. — 14.8.2013
  • karel.vavra : pokud ale pouzivate MySQL, na pohledy rovnou zapomente... — 15.8.2013
  • michal.aichinger : Karle, proč? Máš nějaké argumenty, nebo je to jen výkřik do tmy? — 16.8.2013
  • dzejkob : Troufnu si odpovět: 1. parametrické views musíte beztak řešit v aplikační vrstvě, 2. problémy s view definers při migraci / exportu / importu, 3. pokud chcete views naplno používat a něco z nich poskládat pak si nabijete čumák - protože views nemají žádnou výraznou výhodu oproti subqueries, nepoužívají žádnou hlubší logiku - funguje to pouze v rovině nějakých temporary tables (prostě subquery se někam komplet celé zpracuje a pak výsledek se joinuje). 4. neumí ani tu nejprimitivnější formu materialized view. Všechno tohle z views v mysql dělá jakousi blbinku pro parádu, aby se neřeklo, že to tam není. Z mého pohledu ale mysql views NEUMÍ. — 16.8.2013
  • Anonym : Kdo používá Doctrinu, tak třeba musí řešit jak formátovat DQL dotazy. Což z hlediska smyslu dotazu je úplně to samé. — 16.8.2013
  • mkoubik : V Doctrine se také snažím psaní DQL vyhnout a kde to jde používám QueryBuilder. Kromě toho že mi to přijde přehlednější (to je možná jen moje deviace) se s tím líp pracuje a nemusejí se skládat stringy jako ve variantě 2). — 16.8.2013
  • karel.vavra : j-hrb to docela shrnul. Problem je hlavne vykon (nebo aspon byl jeste ve verzi 5.1 myslim, nevim jak je to ted - nemam cas ani chut si s tim hrat znova). MySQL ma obecne problem pri operacich nad VIEW vyplodit rozumny exekucni plan. — 16.8.2013
  • Kit : To víme, že MySQL dělá jazyku SQL medvědí službu. Programátoři kvůli jeho neschopnosti transakční logiku zbytečně přesouvají do aplikace. Vůbec se mi nelíbí generování SQL dotazů za běhu slepováním. Vždyť je to programovací jazyk. Funkce eval() je odsuzována v PHP, Javascriptu i dalších jazycích, ale v SQL se s ekvivalentem zachází, jako kdyby to bylo úplně normální. — 29.8.2013
  • JanVoracek : Ono slepování za běhu je jen „skrytou touhou“ po DSL, jakým je například LINQ. S funkcí eval to nemá nic moc společného – prostě vytváříš kód, který se spouští v úplně jiném prostředí. Otázkou je jen, jestli chceš ve zdrojovém kódu programu míchat dva rozdílné jazyky nebo to přenecháš nějaké knihovně a svůj kód si špinit nebudeš. — 30.8.2013
  • pavel.stehule : slepování má dva efekty - pozitivní - může snížit délku kódu, a negativní - v podstatě dost komplikuje (až vylučuje) SQL optimalizaci - což se u datově nenáročných aplikací vůbec nemusí projevit a naopak u datově náročných aplikací - velký objem zpracovávaných dat, komplexní dotazy - případně obojí, to může být vražedné. Je v povaze věci, že aplikační programátoři vidí prvé, a DBA druhé. Moje zkušenost je taková (a vzhledem k tomu, čím se zabývám, tak se dostávám primárně k problematickým aplikacím), že by programátor měl vědět vždy velice dobře jaké SQL příkazy a v jakém počtu do db posílá. U datově orientovaných aplikací jsou operace s databází primárním úzkým hrdlem a to, co skvěle funguje na malé testovací, vývojové databázi, může být otravné nebo nebo nepoužitelné na databázi v aplikaci provozované 5 let. — 30.8.2013
  • Kit : Míchání rozdílných jazyků do PHP je naprosto běžné. HTML, Javascript, CSS, SVG,... - proč tedy ne SQL? Jen je potřebné delší stringy zapisovat kulturně. Myslím si, že Heredoc je skvělý šablonovací systém, který se hodí na všechny zmíněné jazyky včetně SQL. Jakákoli jiná abstrakce typu skládání dotazů, ORM nebo Smarty je jen další zbytečný jazyk navíc. — 30.8.2013
  • mkoubik : Pokud Javascript, CSS a SVG generuješ PHPčkem, tak děláš něco špatně. U míchání PHP s HTML taky, ale tam je to složitější. Dodatek: pokud nepíšeš transpiler. — 30.8.2013
  • Kit : Javascript a CSS mám zpravidla fixní a není tedy důvod je dynamicky generovat. Jednodušší SVG a HTML generuji přes Heredoc nebo třídou XMLwriter, složitější třídami DomDocument a XSLTprocessor. — 30.8.2013

Pro zobrazení všech 10 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.

Aktuální otázky v rubrice Programování: PHP

Otázky uživatele robo.balasko