Newsgroup: it.comp.macintosh
Titolo: Piccole esigenze di database

 erede 
di CocoaSQL, opensource e freeware e che mi permette di gestire le 
viste. Una soluzione con sqlite3 però l'avrei apprezzata di più, il 
supporto a sqlite3 per Sequel Pro è previsto per il futuro ma non c'è 
alcuna data.
*asternersi riposte che includono fogli di calcolo

 *asternersi riposte che includono fogli di calcolo
io mi astengo dalla risposta che includa fogli di calcolo :-) ma definisci
meglio la "piccola esigenza". perché sparare con MySQL a una piccola
esigenza, vabbe', è interessante... :-)
filemaker non ha versioni "lite"?
d.

 filemaker non ha versioni "lite"?
Bento, di cui ho provato la trial e francamente non mi piace, è 
_lentissimo_ e ha troppi fronzoli.

 tabella singola per cui cercavo un db da usare "al volo".
singola tabella > numbers
ahah scherzo neh :-)
d.

> singola tabella > numbers
A quel punto se vuoi farci analisi serie, pivot o meno, meglio excel
che ha strumenti di analisi statistici un po' più collaudati ed
efficienti. Meglio la versione win sotto parallels che straccia imho
la 2008 mac in quanto a prestazioni.
Certo, se è la lista della spesa è un overkill. Se la tabella passa i
50mila record allora te ne accorgi.
PR

 tabella singola per cui cercavo un db da usare "al volo".
Premetto che io uso FileMaker, ma ci sarebbe il database di
OpenOffice/NeoOffice, da valutare.
-- 
Per rispondere, togliere -NOSPAM- dall'indirizzo.


certo, gliela compri tu la licenza di parallels, di windows e di
office per windows da installare per usare un foglio di calcolo PER
FARE STATISTICA?
Allora meglio R, e' gratis ed e' fatto apposta.
E cmq UN FOGLIO DI CALCOLO NON E' UN DATABASE E NEANCHE UN PROGRAMMA
DI STATISTICA!!!
Ciao Jack

 Ciao Jack
E nemmeno un word processor, l'hai dimenticato.
Dontknowjack.



Hit the road, jack (cit.)
d.

 DI STATISTICA!!!
sì! incazzato, ti voglio!
:-))
d.

 esigenza, vabbe', è interessante...
Perche' uno e' masochista: in questo MySQL e' esemplare, fa ugualmente
cagare per tutte le moli di dati!
-- 
-riko

 alcuna data.
Alcune semplici proposte:
1. Django. Scrivi la definizione della tabella e gli dici di generarti
il manager. Sei webbased (ma puoi fare girare in locale senza webserver
esterni e/o da installare e/o da configurare) e sqlite3 based. Se ti
incuriosisce ti faccio vedere un esempio che mostra come sia
dannatamente piu' semplice di quello che pensi.
2. E' la volta buona per vedere CoreData.
-- 
-riko

 DI STATISTICA!!!
Quoto, quanto cazzo quoto.
-- 
-riko

 2. E' la volta buona per vedere CoreData.
Sě č no. Mi rendo conto che puň essere comodo e gli darň un'occhiata 
anche se dovrei prima entrare nell'ottica di Django, cioč non so manco 
se devo configurare ambiente, librerie e quale versione di py viene con 
Leopard.
Diciamo che preferivo una applicazione che fosse:
- Cocoa
- pensata per l'utente e non per il programmatore
Se puoi fare un video tipo quelli fighi "blog in 7 minuti" lo guardo 
volentieri.

 cagare per tutte le moli di dati!
Con esigenze molto ridotte non ho mai sentito neanche l'esigenza di 
approfondire la diatriba my-postgres, capisci che se ci devo tenere 
traccia della spesa, dei libri sullo scaffale e dei CD musicali non 
incontro certo i limiti del db.

 DI STATISTICA!!!
  E nemmeno un ambiente di programmazione in Visual Basic!
-- 
Nicola D'Agostino
<!-- 
http://www.nicoladagostino.net
 -->
<!-- 
http://www.storiediapple.it
 -->
<!-- 
http://www.nezmar.com
 -->


potrebbe essere interessante.
Ciao Jack

 volentieri.
Dubito che si possa scendere sotto i 15 minuti ;-)
-- 
http://myretrocomputing.altervista.org

 la 2008 mac in quanto a prestazioni.
meno male che parlava di soluzione semplice e free... qui, al di là
del'artifizio della virtualizzazione, ci passano 3 licenze mica da
poco...

 Dubito che si possa scendere sotto i 15 minuti ;-)
Non so, era un riferimento lato a "Tutti pazzi per Mary".

 potrebbe essere interessante.
Lo sembra molto.

 cagare per tutte le moli di dati!
Minchia i fan boy dei database adesso. :O
-- 
http://nekonin.tumblr.com/

 Minchia i fan boy dei database adesso. :O
Dai, non ci credo se dici di non aver _mai_ visto un flame tra mysql e 
postgresql.

 postgresql.
No, è che mi piace rimarcare la pochezza di certi fanboismi, soprattutto 
alla luce delle modeste esigenze chiarite nel thread. ;)
-- 
http://nekonin.tumblr.com/

 Non so, era un riferimento lato a "Tutti pazzi per Mary".
Eh non ho colto. Io comunque mi riferivo a questo che dura appunto 15
minuti:
http://media.rubyonrails.org/video/rails_blog_2.mov
-- 
http://myretrocomputing.altervista.org

 incontro certo i limiti del db.
Si, i limiti li incontri. Non sulla mole. Ma sul supporto casereccio
allo standard, bachi vari, etc etc etc. E' semplicemente una palla
lavorarci.
Nota che per le tue esigenze io *non* ti stavo consigliando Postgre, va
bene il fanatismo, ma qua saremmo alla demenza (se tu avessi gia' su
postgre avresti impostato diversamente tutto). 
Il mio consiglio sarebbe sqllite con sopra Django o CoreData.
Postgre e' un overkill. MySQL pure, e in piu' e' un oggetto peggiore.
-- 
-riko

 volentieri.
Capisco. Il punto e' che se il tuo problema e' veramente semplice come
dici puoi cogliere l'occasione per imparare una di queste due
interessanti tecnologie. Anzi, CoreData lo impari. Django di fatto no,
visto che di fatto scrivi il modello e poi ti appoggi interamente alla
sua capacita' di generare automagicamente l'interfaccia di
amministrazione.
-- 
-riko

 potrebbe essere interessante.
IMHO postgres rimane *comunque* sovradimensionato per quello che deve
fare. IMHO lo strumento piu' adatto e' SQLite, mascherato sotto
qualcosa.
Come DB Firebird sarebbe migliore, ma potrebbe essere piu' noioso
metterlo su, e siccome ha esigenze praticamente nulle, tanto vale
SQLite.
-- 
-riko

 di la', mi sono scoraggiato...
O-O
SAP, saranno cinque minuti si e no. Ma non lo dico da Fanboy, eh.
Non devi impostare server: per sviluppare usi il suo integrato.
Anche come DB di default usi SQLite, gia' pronto.
-- 
-riko

 pero' al terzo ostacolo ricordo che mollai li'.
Si ma *non* ci sono tre ostacoli. Quello e' il problema. :P
-- 
-riko

 amministrazione.
Cioč quello che č illustrato qui
<
http://docs.djangoproject.com/en/dev/intro/overview/#a-dynamic-admin-int
erface-it-s-not-just-scaffolding-it-s-the-whole-house>
giusto?

 giusto?
Si.
-- 
-riko

 scrivere una singola linea di codice o giu' di li.
Avevi perfettamente ragione, ho seguito l'introduzione di XCode ed è una 
cavolata, in pratica con l'oggetto IB per costruire l'interfaccia è 
tutto automagico.
Quello che mi dissuadeva era la mia scarsa familiarità con NSDocument.
Il prossimo passo è creare una classe per gestire un campo calcolato 
sull'update.

 tutto automagico.
Eh, te lo dissi perche' lo feci. :P
-- 
-riko