Jasne pro zakladni veci je to "good enough" a sem s tim v pohode (jen to 'AND' / 'OR' tam je jak pest na oko, nedej boze ze bych mel vnorene podminky kde budu muset vnorovanim resit prioritu jednotlivich AND / OR .. to pak zacnu zanorovat pole do sebe..). Jde mi o to ze ostatni to maji jen jako jednu z moznosti takze kdyz zacnu skladat neco slozitejsiho / nedejboze aplikovat ruzne ACL filtry a pravidla tak proste sahnu pro builderu.
Pokud naopak budu pracovat s necim kde je dotaz "staticky" tak neni nic lepsiho nez stare dobre SQL a pak pouzit naky mapper nebo prave DQL / HQL .. kde se sice musim ucit trosku odlisnou syntax (coz ale prumerne cvicena opice zvladne za 2 hodiny) ale zase mi odpadne prace s mapperem.
Proste kazdy ten zpusob ma sve vyhody / nevyhody a vznikl za nakym ucelem. Smahem to odsoudit a tvrdit ze ostatni reseni jsou "Tedy to čemu rád říkám rovnák na ohýbák" je takove.... nevim prijde mi to proste hrozne kratkozrake.
prece jen jednoduchy priklad
SELECT * FROM schedule
WHERE
(schedule.date_from IS NULL OR schedule.date_from < :date)
AND
(schedule.date_to IS NULL OR schedule.date_to >= :date)
AND
country = :country
vs
[
[
'schedule.date_from IS NULL',
'OR',
'schedule.date_from <' => $date
]
'AND'
[
'schedule.date_to IS NULL',
'OR',
'schedule.date_to >=' => $date
],
'AND',
'country' => $country
]
Tak mam osobne celkem jasno co budu chtit cist a to mame jeste docela jednoduchuou podminku.. navic u toho prvniho retezce mi napovi IDE a okamzite me klepne pres prsty kdyz se nekde ukliknu
Přečteno 20 744×
Přečteno 18 591×
Přečteno 17 805×
Přečteno 17 554×
Přečteno 16 260×