db non relazionale

[jimbo0]

salve, dovrei pensare ad una struttura di un database che ospiterà 4 tipi di documenti diversi. Ogni documento ha ~30 campi (testi, liste, megatesti da 10000 caratteri, date..insomma solita roba).
Questi 4 tipi di documenti hanno qualche campo in comune.
Idealmente tutti i campi di tutti i documenti dovrebbero essere ricercabili con un'interfaccia utente.
Ecco, vorrei evitare le megatabelle (4) di un db mysql (come dice il titolo non ci sono relazioni tra documenti)

Magari qualcuno ha già percorso strade simili, quindi chiedo qui: oltre alla struttura generale, avete consigli su tecnologie e metodi? Ad esempio, quali design pattern adottare?

Devo buttare php e andare di servlet (sapendo che il db ha molti campi ma avrà circa 1000 tuple in tutto)?
(Si pensava ad un webservice restful come output finale, ma ora mi interessa la parte del db).

Per chi ha esperienza con strumenti simili, credete che Solr o Elasticsearch possano essere utili? O dovrei orientarmi a questi solo se mi è richiesta una ricerca fulltext (non lo so ancora)? Per quanto riguarda Elastichsearch non ho ben capito quale parte è commerciale e quale è opensource.

Insomma sono aperto a qualunque spunto utile http://www.iperborei.com/thule/Smile...ies1/smile.gif

[optime]

che vuol dire "vorrei evitare le megatabelle" ?

[jimbo0]

come ho detto sarebbero tabelle da 30 colonne..
credo che non essendoci relazioni tra le entità buttarmi in un db non relazionale sia meglio..ma ho poca esperienza in merito

[Vincent.Zeno]

sono curioso di capire cosa ti porta a credere che possano esserci "problemi" nell'utilizzare 30 campi (cifra per nulla alta) in un qualsiasi db. se non hai relazioni tra record semplicemente non impostare relazioni che non esistono

edit
scusa: m'era sfuggito che ci sono gruppi di 4 documenti. quindi la relazione potrebbe esserci, oppure puoi usare identificativi per raggruppare.
ma il problema mi pare continuare a non esserci

[optime]

infatti: cosa impedisce di gestire 4 tabelle non relazionate con un db relazionale? tra l'altro di modestissima entità...

[LuciferSam86]

AFAIK PostgreSQL supporta anche strutture non relazionali. Mai provato realmente, ma solo con dati "fuffa".

NB: l'articolo linkato non tiene conto di JSONB supportato dalla 9.4.qualcosa e di qualche indice che può aiutarti che hanno aggiunto recentemente.

Altrimenti ce ne sono altri , ma non he provato nessuno.

[jimbo0]

non è che credo ci possano essere "problemi" usando mysql in maniera non relazionale..
semplicemente credo che in questo caso credo siano più calzanti dbms non relazionali quali CouchDB o PostgreSQL oppure i tool di cui parlavo Solr o Elasticsearch..ma non avendo gran esperienza in merito chiedo qui

[jimbo0]

Mi ero orientato verso CouchDB, mi ha attratto l'interfaccia già Restful e l'indexing in Map-Reduce, ma poi ho compreso che le query complesse (le query "contains" ossia il LIKE di sql) non sono il suo forte: dovrei definire centinaia di view diverse.

Ora vorrei approcciarmi a MongoDB che sembra il noSQL document oriented più diffuso, ma non vorrei perderci tempo per poi scoprire che manca una funzionalità importante che a me serve.
Ricapitolo le mie richieste:
-NoSQL document oriented
-non mi interessa molto la possibilità di avere un database distribuito data l'esigua mole di dati totali
-interfaccia rest o simile
-possibilità di fare query complesse (ossia: seleziono i documenti che hanno campo1 che comincia per "a",campo2 che comincia per "1" e campo3="100")

[optime]

Perché ti serve un noSQL?

[jimbo0]

Perché ti serve un noSQL?

beh credo che sia l'ideale, non ho relazioni, ho documenti da memorizzare (alcuni campi dei documenti possono essere liste, quindi con un database tabellare potrebbe non essere l'ideale esplodere i campi con un separatore).
ed un noSQL document oriented calza bene, solo devo trovare quello che mi non mi azzoppi per quello che mi serve .