Newsgroup: it.comp.appl.access
Titolo: Access vs MSDE vs SQL Server vs MySql

Ciao a tutti...
una discussione tecnica piu che una risoluzione a problemi.
Secondo voi:
In quale condizione e' meglio usare una basedati piuttosto che
un'altra?
Cioe'....in quale occasione (facendo esempio) usereste Access come
base dati piuttosto che database server tipo mysql/sql server?
Inoltre....MSDE lo usereste? in quale occasione?
Avete mai provato MySql e Sql Server? differenze (qualsiasi)?
Mi piacerebbe conoscere i Vs pareri in merito, am soprattuto il
perche' di una scelta poiuttosto che un'altra.
Commenti? pareri? (anche tecnici)

E' una domanda da 20 milioni di dollari di cui aspetto ancora risposta.
Io dico la mia.
1) Con MySql hai le garanzie che puoi avere gli OpenSource
2) SQL non l'ho mai sperimentato
3) Access ne parlano male, ma lo usano tutti. Perché alla fine i brillocchi
e le stelline colorate piacciono a tutti e sinceramente come front-end per
me è il massimo.



Quindi tu dici:
Access (interfaccia)
MySql (basedati)
e MSDE ?

"yQy" <fabrizi...@SESPAMMITISTRONCOtin.it> ha scritto nel messaggio
news:61jpdvkpfpsq7eo06...@4ax.com...

Ogni tanto riesco a dare un'occhiata alle recensioni e prove che vengono
pubblicate sulle riviste di informatica che acquisto.
Per quanto riguarda Access, nel numero 144 di PC-Professionale, viene
definito come un RDBMS non proprio semplicissimo ed intuitivo, ma
sicuramente di una robustezza, flessibilità e programmabilità di assoluto
rilievo. In ogni caso viene comunque considerato un motore che pur
consentendo la gestione di applicazioni sofisticate e professionali, rimane
adatto ad un uso personale o per  gruppi di lavoro circoscritti. Non adatto
quindi a fungere da server per centinaia di accessi contemporanei.
Inoltre, non solamente è un software proprietario, ma l'autore, per motivi
ben comprensibili, lo rende disponibile per le sole piattaforme Windows. (A
meno di ricorrere ad emulatori sotto altri S.O.).
MySQL è invece uno dei più diffusi database (qui non sono ferratissimo xchè
ho le prove da qualche parte in garage), che deve la sua diffusione
sopratutto all'essere il DBMS open-source + veloce in internet, pur
rinunciando ad alcune caratteristiche per il quale non può essere
considerato un vero database relazionale (con l'ultima versione le cose
dovrebbero essere un pò diverse).
Si integra con diversi sistemi operativi, pur prediligendo i sistemi Linux e
cugini.
Non dispone di tutta la parte (credo si dica Front End) con la quale
generare l'interfaccia utente: maschere, report, ecc... Tuttavia si presta
ad una marea di tecniche di interfacciamento, sia open-source, sia
proprietarie.
Personalmente, per certe applicazioni tenterò la migrazione a PostgreSQL
http://www.postgresql.com/
Gira su piattaforme Linux-Unix, Windows, ed altre; viene definito il +
avanzato RDBMS open-source, ed è anche molto veloce.
Nonostante questo, per tante altre apllicazioni, viva Access.
E viva questo NG.
Ciao a tutti.

Ciao a tutti.
Ciao ! :))

 
budget limitato + tanti utenti + applicazione semplice = mysql + php
budget limitato + tanti utenti = mysql + access
obbligo ms + tanti utenti = mssql + access
ovviamente, si tratta di opinioni...
-- 
+-------
| Paolo opg
|
| janickg ( at ) hotmail ( dot ) com
+-------

 sql server, gratuito)
Ammetto la mia ignoranza! Non sò cosa sia MSDE... (anticamente programmavo
in COBOL, devi capirmi, sigh!)
Ciao!

in COBOL, devi capirmi, sigh!)
Ignoranza? non direi :)))))
anzi, grazie per le tue opinioni preziose
Ciao :)

ovviamente, si tratta di opinioni...
quello che avevo chiesto.
E' molto interessante questo thread.
:)

"yQy" <fabrizi...@SESPAMMITISTRONCOtin.it> ha scritto nel messaggio
news:61jpdvkpfpsq7eo06...@4ax.com...

Esiste una differenza essenziale tra le due accoppiate Acces/MySQL e
Access/MSSQL (poco importa che sia MSDE o SQL Server): a mysql accedi solo
con i comuni driver ODBC, cosa che ti limita enormemente nel'accesso agli
oggetti e nelle performance; con MS SQL e ADO accedi al database in modo
praticamente nativo.
Questo offre essenzialmente due vantaggi:
1) coerenza nell'interfaccia che usi per sviluppare, e quindi meno tempi
morti;
2) possibilità di gestire tutto (struttura delle tabelle, indici, stored
procedures, triggers E UTENTI!!!!) dalla finestra di Access. Con MySQL non
ti è consentito.
Un'altra differenza sostanziale è che MySQL non supporta in modo efficace le
subselect negli update.
Vedo di spiegarmi meglio: immagina di dover fare un update dei record di una
tabella con dei lookup in un'altra o con una formula condizionale, ebbene:
per SQL Server e MSDE sono operazione normali, performanti e funzionali, per
MySQL sono solo rogne (E' una funzionalità recente che non funziona a
dovere).
Per esempio una cosa del tipo "update tabella1 set campo1=1 form tabella1
inner join tabella2 on tabella1.chiave=tabella2.chiave where ..." in MySQL
non si fa e dovresti farla usando i cursori, che in ODBC non ci sono...
Non parliamo poi delle Stored Procedure...
Dal punto di vista di MSDE, che dire?
Sebbene manchino tutti i tool di amministrazione, si possono usare i tool di
amministrazione di MS SQL Server versione Trial, che vedono MSDE come un
normale SQL Server.
In effetti MSDE non è altro che un SQL Server senza alcune funzionalità
avanzate, come la replica, e con performance "castrate": database max 2GB,
accrocchio che riduce le prestazioni quando gli utenti collegati sono + di 5
(attenzione COLLEGATI CONTEMPORANEAMENTE!!!!!!!!).
Se hai bisogno di altro continuo volentieri.
Giorgio

 Ciao :)
Messa così perchè non sviluppate entrambi in C++?
E' evidente che quando scegliete Access come ambiente di sviluppo vi legate
ad una piattaforma: gira solo sotto Windows!!!!!!!
Per il server è diverso: se vi attenete all'uso di chiamate ODBC standard e
ANSI SQL potete mettere sotto che motore SQL desiderate, da un freeware del
cavolo a un RDBMS per delle Corporate...
E' anche evidente, però, che non ne sfruttate le caratteristiche peculiari.
Parlare di performance, messa così, è solo ridicolo.
Bye.

 
access + postgres
o forse anche access + mysql: pare che con la versione 4 abbiano tolto 
alcune delle limitazioni che avevano le versioni precedenti. per l'uso 
che ne faccio io, mi interessa soprattutto la parte relativa alle 
subquery: con le vecchie versioni non erano possibili.



Dalla v. 4 ci sono.
Resta il problema della limitata integrazione che è comune a tutti i db
accessibili via ODBC.

 dovresti farla usando i cursori, che in ODBC non ci sono...
???? che significa???
Ciao, Sandro.
--------------------------------
Inviato via 
http://usenet.libero.it

Se hai bisogno di altro continuo volentieri.
Certo...conoscere sempre di piu queste cose aiuta...non solo me, ma
tutti...l'esperienza altrui serve anche a migliorare ed accrescere la
nostra...:)
Ciao

 Ciao
Ciao.

 Inviato via 
http://usenet.libero.it
Ciao

 ha scritto nel messaggio
news:bbk9k9$let$1...@newsreader.mailgate.org...

Rileggendo mi accorgo che sono stato piuttosto criptico...
Quello che intendevo dire è che in MS SQL e MSDE esistono degli oggetti
nell'RDBMS che si chiamano cursori e che servono essenzialmente per poter
operare via Transact-SQL direttamente sui recordset. Per esempio:
1) posso assegnare a un cursore un recorset
2) nel cursore vado avanti e indietro a piacimento con libertà di updatare
le righe
Questa cosa la fa il server, non il client, ed è inseribile in uno statement
SQL.
Questa opportunità è alternativa e analoga all'uso degli update con
subselect.
Via ODBC dovresti aprire un cursore ODBC e scorrerlo avanti e indietro dal
client...
Forse mi sono spiegato meglio così?
Mah...

 lontane dalle performance di ADODB con MSDE.
Con che numero di record?



Io mi accorgo delle differnze gią estraendo 25.000 record della mia tabella
delle righe scontrino...
Ciao.


Perdonami, ma non ti seguo.
Premesso che 25 mila record per un db anche mediocre sono una sciocchezza.
Ma intendi dire che apri contemporaneamente 25 mila record? Magari con un
datagrid?
Senza stare a fare troppa filosofia del cavolo, credo che difficilmente
possa servire un recordset che contenga piu di un centinaio di record,
semplicemente perchè una "lista" di troppi record è ingestibile.
Quello che posso testimoniare io, invece, è che con MySQL come BE, Access e
le tabelle collegate ODBC si riescono a gestire molto tranquillamente
svariati milioni di record.
Tutto sta a non portarseli tutti in locale per lavorarci, ma so già che, su
questo, sei daccordo con me ;-)


 ha scritto nel messaggio
news:212Z210Z230Z116...@usenet.libero.it...

Infatti sono d'accordo con te.
Quando sono entrato in azienda lo scorso anno, avevo intenzione di
sostituire l'SQL Server 7 con un MySQL.
Ho provato a fare dei test comparativi di ordinamento, join, filtro su
tabelle identiche su entrambi i db e con varie quantità di record.
MySQL si è dimostrato leggermente più veloce di MS SQL per volumi di dati
limitati. Al crescere dei volumi le performance si sono rivelate veramente
molto diverse fino a raggiungere differenze prossime al 10x sulla mia
tabella dei movimenti che, all'epoca, erano circa 4 milioni e mezzo (oggi
sono 6 milioni).
A questo aggiungiamo che all'epoca non potevo usare la clausola UPDATE
usando le comodissime subselect... e che la gestione della sicurezza del db
era assolutamente disgiunta dalla sicurezza di NT.
Ho deciso di rimanere in SQL Server...
Bye.
Giorgio

 usare msde?
cut
intervengo solo per fare una considerazione.
prendiamo una tabella (solo una per semplicita') e prendiamo un record
singolo di dimensioni medie, avremo qualche campo numerico, qualche data,
diversi campi testo e, forse, un campo memo il tutto occupa (in media) 100
byte, ma esageriamo pure, 200 byte.
Significa che per arrivare a 2Gb dobbiamo inserire 10.000.000 di record, e
stiamo parlando di record piuttosto grossi, non mi sembra che sia un limite
preoccupante, fino a 3/4 anni fa neanche c'erano HD di queste dimensioni.
comunque la differenza sta' nella condivisione, se non devi condividere tra
piu' di 3/4 utenti e il db non e' enorme, non vale la pena di lasciare il
Jet, ma se le cose cambiano...
Sib

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:ohIDa.76929$g92.1...@news2.tin.it...

No, ci sono anche altre considerazioni: immaginiamo che tu acceda a un db
aziendale tramite una VPN da remoto, per esempio che tu abbia la necessità
di consultare un listino di 20.000 articoli tramide una connessione
analogica a 56K...
Secondo te vale ancora la pena di mantenere il Jet come motore?
Il problema è che quando usi il jet TUTTA la tabella viene trasferita nella
RAM locale, questo significa che trasferisci dicine di KB, centinaia di KB o
molti MB...
Non è solo un problema di concorrenza di utenti.
Tra le altre cose il TUO jet locale va a scrivere FISICAMENTE nel file
remoto. E se la tua scheda di rete ha un problema? Cosa fai, butti 1.000.000
di record?

 "Sib" <si...@SPAMiol.it> ha scritto nel messaggio

Ovviamente.
fermo restando che, il jet e' meno stupido di quanto si possa immaginare in
questo senso.
ad es, una query filtrata su un campo indicizzato non ti scarichera' affatto
tutto il record, ma il jet provvedera' ad andarsi a cercare "fisicamente" i
record cercandoli sull'indice (con algoritmi specifici) e impegnando molto
meno la connessione.
resta fermo che l'esecuzione avviene tutta in locale, ma almeno questo c'e'.
Sib