← Uz sākumu

Aizrāvos ar SQLite

2004. gada 14. oktobrī, 9 komentāri

SQLite is "typeless". This means that you can store any kind of data you want in any column of any table, regardless of the declared datatype of that column. (See the one exception to this rule in section 2.0 below.) This behavior is a feature, not a bug.

Не очень плохо
Иметь три жены,
И очень плохо
С другой стороны!

Tu atbildi augstāk redzamajam komentāram. Atcelt

Gravatar Peeteriz

2004. gada 14. oktobrī, plkst. 10:11

Un šāds typeless uzlabo performanci ? Būs man tabulā kolonna, kurā glabāšu naudas summu, tad ņemot sum(nauda) ko jamais darīs ar necipariem ? Lamāsies ? Uztvers kā NULL ? Kā ar validāciju un integritāti ?

Manuprāt SQL vienkāršot nevajag mēģināt - tās fīčas tur ir ar dziļu iemeslu.

Gravatar Livingston

2004. gada 14. oktobrī, plkst. 10:25

"Typeless" ir fīča tikai tiem, kas nevar/negrib uzturēt normālu DB. Peeteriz jau norādīja uz problēmām - ja cilvēki varēs ierakstīt ciparu vietā burtus, tad kāds to arī izdarīs. Bet pārbaudīt datu pareizību ārpus datu bāzes vienmēr (99.9% gadījumu) ir stulba ideja.

Gravatar Delfins

2004. gada 14. oktobrī, plkst. 10:51

nu nepiekritišu, dati ir jāparbauda, - vispirms uz sql injection, un lidz ar to "paceļam" parbaudam pašus datus. turklāt likt datubāzē neparbaudītus datus ir 99.9% stulba ideja

Gravatar e-remit

2004. gada 14. oktobrī, plkst. 11:38

pietiek jau ar MySQL stulbajām idejām - nekādas ārējās atslēgas, NOT NULL laukos var bliezt iekšā NULL, ka prieks... datu integritāte pārbaudīta tikai klientā.

Gravatar Livingston

2004. gada 14. oktobrī, plkst. 12:17

SQL injection nav DATU PROBLĒMA, bet gan stulbu dinamisku DB pieprasījumu problēma. Nebūvē pieprasījumus no lietotāja padotajiem datiem un viss būs kārtībā. Piemēram, ja Tu taisi search formu un dinamiski būvē pieprasījumu, tad arī rodas pamats uztraukties par SQL injection. Ja tiek izmantoti "nedinamiski" SQL + bind variables, tad par to nav jāuztraucas.

Jebkurā gadījumā, datus pārbaudīt datu bāzē ir vienkāršāk un ātrāk. Tas pats un vēl lielākā mērā attiecas uz datu integritāti - klienta galā gandrīz nerealizējams uzdevums.

Kopsavilkums - stulbi ir ļaut izpildīt nezināmus pieprasījumus datu bāzē, bet normālā datu bāzē likt nepārbaudītus datus ir OK.

Gravatar Kaklz

2004. gada 14. oktobrī, plkst. 12:27

Ta nu ar te salīdzināja tautieši SQLite ar PostgreSQL vai Oracle vai vēl sazin ko. SQLite ir jālieto attiecīgās vietās un attiecīgās reizēs. Vecais labais teiciens - 'Use the right tool for the right job'. Neticu, ka SQLite kāds izmanto priekš biznesam svarīgām funkcijām. Manā izpratnē SQLite izceļas tieši ar to pašu, ar ko PHP - vienkārši un ātri var sasniegt vēlamo rezultātu - nav jācīnās ar lietotāju tiesībām, nav problēmu ar datubāzu pārcelšanu un citas lietas. Manuprāt, SQLite ir ideāls rīks priekš minimāliem web projektiem. Cik daudz nav dzirdēts, ka cilvēki uz apgraizītiem web hostinga risinājumiem grib būvēt dinamiskas lapas - katrs izdomā savu teksta failu formātu, katrs nodarbojas ar viņu papildināšanu un apstrādi, izgudrojot arvien jaunus divriteņus. Te nu ir īstā SQLite vieta - aizvietot triviālu datu glabāšanu teksta failos ar visiem saprotamu un pieņemamu SQL interfeisu. Tieši tāpēc arī PHP vīri ir iekļāvuši viņu PHP5 komplektā.

Gravatar Peeteriz

2004. gada 14. oktobrī, plkst. 13:01

Manuprāt arī vistriviālākajiem uzdevumiem vislabāk ir lietot sistēmu ar normālu funkcionalitāti - Oracle/MSSQL/PostgreSQL.

Kāpēc lai jamos nevarētu lietot kautvai priekš 10 ierakstu datubāzītes weblapai ? (Ja neskaita Oracle licences maksas, protams - tad ir vieta Postgre).

Vismaz nebūs tizlas problēmas, kad ievajadzēsies bik sarežģītāku pieprasījumu uzrakstīt, bet tā lite valoda kautko piespiedīs darīt čerez ž.

Gravatar Livingston

2004. gada 14. oktobrī, plkst. 13:02

Tā jau ir, ka visur nevajag ne Oracle, ne PostgreSQL. Ja uz jautājumu "cik svarīgi ir dati, kas glabājas datu bāzē?" var atbildēt ar "pāris stundas/dienas un viss būs uzrakstīts no jauna", tad jau pie kājas. Ja skaidri zini, ka tie ir temporary dati, par kuriem pēc gada vai 5 neviens vairs neinteresēsies, tad arī pie kājas.

Tiklīdz prasības palielās, vajag arī rūpīgāk piedomāt pie datiem. Vienkārša patiesība - dati parasti dzīvo ilgāk par jūsu PHP kodu (vai vispār aplikāciju kā tādu). Jauns gads, jaunas prasības attiecībā uz dizainu vai funkcionalitāti, aplikāciju uzlabo vai veido jaunu. Bet datus turpina izmantot tos pašus.

Gravatar Mr.T.

2004. gada 18. oktobrī, plkst. 19:07

Sen jau zināms, ka "Feature is a documented bug" :)