MySQL ili JSON

Baza za cuvanje podataka. XML/JSON za transport.

Ako nema relacija i ide JSON razmene preko web-a onda mozda treba razmisliti o MongoDB (www.mongodb.com) kao NoSQL resenje pored MySQL.

JSON i XML se mogu smestati direktno kao vrednosti u MySQL te tako smisao pitanja je malo pogresan.

Dok ti tabele budu do 1,000 slogova trpaj ih u sta hoces. :)

E sad, od ovoga sto si navela, samo MySQL ima smestanje - ne postoji nacin da smestis podatke u xml ili json. Mozes da ih formatiras kao tekstualni fajl, i da taj fajl spustis na fajlsistem, ali to nije cuvanje podataka, to je, da izvines, vic. Generalno, cuvanje bilo cega na fajlsistemu je lose resenje u web okruzenju, jer ne skalira sjajno i dosta je komplikovano za izvesti. Neka resenja su :

- Smestis u bazu, npr. MySQL
- Smestis na shared filesystem (kazem, komplikovano)
- Smestic na object storage (tips S3), isto kao na filesystem - ali bolje skalira
- Smestis u neki specijalizovani storage, tipa gore pomenuti Mongo, koji nije lose resenje za JSON.

Sve ovo je problem jer, po meni, ovi requirements su cudnu, da ne kazem glupo. Ako hoces ozbiljnu pomoc, realno, daj ko ti je to dao kao requirements, da rastumacimo sta to tacno znaci, jer tako je malo cudno....

Mada, kazem, tabela sa par hiljada redova, trpaj de 'oces.

Ako korisnici treba da preuzimaju podatke kao podatke a ne da ih sajt prikazuje onda je SQLite vrlo zgodno rešenje. korsinici dowloiaduju datoteku i rade dalej s njom šta im treba.

Ako ih staviš u MySQL odaih svakako moraš prebaciti u na primer JSON da bi ih korsinici preuzimali.

To je nešto za mene. Sama sam sebi zadala zadatak, tačnije iskomplikovala nešto što se rešava običnim nizovima.



SQLite nije podržan (slažem se da bi bolje odgovarao). Krajni korisnik videće u jednom trenutku nasumično samo jedan slog iz baze, tačnije tabele.



MongoDB nije podržan.


Ako se odbace XML i JSON, ostaje mi samo MySQL,

Ovo ništa ne znači

Zašto onda različite tabele? Zašto ne jedna tabela ID, tip, naziv, opis?

Zašto baza podataka kada nema veze, join i slično?

Zašto misliš da NULL polja smetaju bazi podataka?

A kako će podaci stići u tabelu? Znači li to da administrator sajta ne može da doda, izmeni ili obriše slog?

A kako to može JSON fajl, a ne može bilo koji drugi fajl? Recimo, flat tekst fajl sa fiksnim slogom. Ili JS fajl gde su podaci već smešteni u niz, pa su odmah u web aplikaciji.

Prvo znači da izvor podataka ne zahteva neku specijalnu zaštitu.

Drugo. Normalno da će administrator moći da ažurira podatke (ažuriranje je opciono i nepotrebno jer su podaci takvi da gotovo ne zahtevaju nikakve izmene). Prema krajnjem korisniku-klijentu je samo izlaz.

Tabela i .txt datoteka su OK za jednostavne podatke. Ali, ovde će biti jedno polje neodređene dužine iz koga će se generisati informacija u formatu novinarskog članka (ne, NIJE blog, sajt sa vestima i slično).

Ok, posto neces da ulazis u pricu o cemu se radi, ja cu biti vrlo prost: Ako web sajt treba da cita iz neceg, onda je mnogo bolje da to bude relaciona baza nego fajl. Ako su to dva jedina izbora, po meni baza je mnogo bolje resenje. Ako je MySQL jedina, molim lepo, to je fina baza, odlicna baza, nista joj ne fali.

Ako nisi sigurna kako da organizujes strukturu, relacione baze su matora materija i teorije ima mnogo. Normalne forme. Neces pogresiti ako ides tako. U bazi sa par hiljada redova je tu kraj, nema sta dalje da pricamo. Format izlaza je ocigledno dokument, tj. html, tj. sajt - nema sta da saljes, ocigledno nije API vec prezentacija ka korisniku.

Ta prica "jedno polje neodredjene duzine" mi je malo cudna, ali ti neces da pojasnjavas, pa molim lepo. Imas text tip polja, spakuj se u njega.

sto rece @djoka_l onda JS file sa objektima ili ti nizovima za laksi dzej plus son ako je problem mysql pa sa js-om onda strikanje i dodatna obrada ako treba za front :)

sto se tice mysql i json evo malo doc-ova sto bi rekli ovi mladji
https://dev.mysql.com/doc/refm...n/json-function-reference.html

Nije problem organizacija strukture, ni MySQL.
Pitanje sam postavila zbog toga što to polje neodređene dužine (više od 255 znaka) treba da sadrži i HTML oznake formatiranja.


Kad rešim pitanje dizajna (poznati su elementi, samo ih treba redzajnirati) i sredim podatke, kačim da vidite o čemu se radi.

Ako korisniku prikazuješ jedan slog na upit, onda database server.

S obzirom da se podaci samo čitaju i ne menjaju, možeš komotno da strpaš podatke u fajl (čitaj: konfiguracioni fajl) i držiš ga zajedno sa kodom. S obzirom da podataka nema puno, možeš prilikom startovanja aplikacije da učitaš fajl u memoriju i držiš podatke sve vreme tamo. Nema potrebe ni za kakvim skladištem.

Pa ako se ne menjaju, JSON je sasvim solidan za to.

https://www.boltwire.com

Ovo je mini CMS koji koristi princip cuvanja podataka van baze. Vredi baciti pogled, prilicno je minimalistican a zanimljiv softver.

E sad, svako od nas ima licne preference. Ja volim preglednost SQL-a, mada nekad nije najsjajnije resenje (neophodan server - cak i kada se radi o maloj aplikaciji). Nije mi jasno - ako je ovo zadatak koji si sama sebi zadala, zasto odbijas i resenja poput Monga? Sve treba isprobati kako bi mogla naci najbolje resenje za odredjenu situaciju.

Ja sam skoro napravio neki minimalisticki panel za superjednostavni baner menadzer, a smestam podatke u json.
Mislio sam da ih stavim u include fajl kao array, medjutim php kesira include, tako da se mora cekati par sekundi da bi se promene videle.
I da, radi se o svega par zapisa.

Koristio sam ranije i sqlite, ali mi se nije pokazao narocito prakticnim.

Stoga baza, vecina servera sada ima mysql i postgresql.

Mozes i sa "fopen" da citas JSON, potom da dekodiras u citljiv format.

A jel' može i sa (pošto ona radi u PHP-u) json_decode() .. pa da odmah dobije PHP objekt/niz, pa da s' njim radi šta god hoće posle ?

+_-
Sve ima oko PHP na zvanicnom PHP site-u:
http://php.net/manual/en/function.json-decode.php

^^ Hvala što si me podsetio, nisam znao.