Newsgroup: it.comp.lang.visual-basic
Titolo: [?]Come posso imparere i database?

Dunque mi sono sempre interessato di tutto ciň che rigurda la programmazione
ed in particolare VB6, tralasciando perň i database. Adesso mi trovo nella
situazione di saperne abbastanza di VB6 ma assolutamente nulla(o quasi) per
quanto riguarda i database.
Come posso imparare?
Non ditemi MSDN che da li non si capisce un .... acca.Vorre trovare un libro
o un sito( in italiano s'intende) dove posso capire bene i database e i loro
linguggi. partendo da DAO, ADO, fino ad SQL.
Mi potreste consigliare qualcosa?
Grazie a tutti!!!!!!!!
GoodBye By Ged

 GoodBye By Ged
ciao
visto che usi oe
^f -> subject -> "database"
sca'fati anche con google, a me continua a sorprendere quanta roba ci sia in
giro. molti siti me li sono teleportati tanto erano ben fatti.
poi, come nel post di oggi, ripeto:
qui non e' che non vada bene, ma e' molto orientato (vb/access -
vb/sqlserver).
fermati qui, ci sono tipi da cui si impara parecchio (non certo io), ma
senti anche su i.c.s.d., il mondo e' bello perche' e' vario.
--
ciao, j.
www.sundaysw.com

 linguggi. partendo da DAO, ADO, fino ad SQL.
Mi permetto di consigliarti di invertire la sequenza: SQL, ADO e lascia
perdere DAO.
Qualcuno caracollerà sulla sedia sentendomi parlare così, ma cerco di essere
obiettivo. Se devi cominciare, passerà un po' di tempo. Probabilmente (io lo
spero ardentemente) ADO crescerà e DAO ... calerà. Per quanto riguarda SQL
(il linguaggio, non SQL Server) lo metto in testa perchè sono dell'avviso
che prima occorre capire cosa si può fare e con quali scopi, solo dopo si
imparano gli strumenti, i mezzi per farlo. Ti consiglio un buon libro, ma
"senza titolo". Vai in libreria e investi un 50one in un libro che parli il
più possibile di SQL in forma discorsiva e progressiva, non un manuale con
le funzioni in ordine alfabetico. Java ti ha risposto indicandoti anche la
rete e ha certamente ragione. Personalmente penso che, specialmente agli
inizi, un buon libro sia più "tutor" (nel senso che ti accompagna su per la
china) di mille articoli presi qui e là un po' alla rinfusa. Quelli, IMHO,
servono per approfondire e migliorare. E poi, vuoi mettere il piacere di
sfogliare un libro piuttosto che le pagine di un sito o i fogli stampati e
volanti?


Sent: Tuesday, July 16, 2002 2:53 AM
Subject: VB-2-the-Max Update: Learn the .NET Framework
FINAL THOUGHTS--AN EXCERPT FROM "BUILDING WEB SOLUTIONS WITH 
ASP.NET
 AND
ADO.NET
"
By Dino Esposito (
desp...@vb2themax.com
)
From the perspective of programmers building data-centric applications,
ADO.NET
 is definitely a quantum leap. The object model is elegant and clean,
and the choice of which language to use is no longer a serious issue--the
ADO.NET
 is powerful and effective, to say the least!
For far too long, accessing databases in Windows has been painful. An
inevitable dichotomy had to be faced and resolved--either you go for the
simplest code or for the hardest: no compromises, no shortcuts, and no
trade-offs. You could take the Visual Basic route and fall in the capable
hands of ADO or make yourself a brave programmer and take an enlightening
journey into the depths of OLE DB. Ease of development versus
fast-but-quirky and error-prone code--that was the choice prior to the
advent of .NET.
ADO.NET
 provides a common API for writing data-driven applications no matter
which application model you choose--Web forms, Windows desktop applications,
or Web Services. The language neutrality of .NET takes the rest and crosses
out any pending threads about which came first: the Visual Basic egg or the
C++ chicken. 
ADO.NET
 takes the best of both worlds and weds together the
simplicity of ADO and the effectiveness of raw OLE DB. In doing so, it also
clears out some of the housekeeping code that made ADO somewhat slow and
abstracts the data model that made OLE DB somewhat so tedious to understand
and boring to use.
For people who spent time and money on ADO, 
ADO.NET
 is a double-edged sword.
On one hand, you can only enjoy such a powerful and modern object model. On
the other hand, you soon realize that 
ADO.NET
 means heavy changes to your
code. As harsh as it may sound, with 
ADO.NET
 a large part of existing ADO
code suddenly becomes legacy code. No matter how long ago you wrote
it--legacy is a timeless concept. You are likely writing code today that
will be marked as logically obsolete by the time you finish it. Logically
obsolete is not a condition that invalidates code. Fortunately, code will
still work. It simply means that you're on a track that would head you,
years from now, into a dead-end track. But along the way there are a number
of switches that you can use to divert your code back on the right track.
What's the moral of the story? You will be able to reuse your existing ADO
skills much better than your existing ADO code. So the key question can be
rephrased like this: Is 
ADO.NET
 something we can really rely upon? Or is it
only the most trendy and fashionable data access layer for this summer's
applications? In recent years we observed a proliferation of data access
models and ADO looked like the definitive tool based on two now-and-forever
underlying technologies: COM and OLE DB. Of course, in late 1998--when ADO
was introduced--no one could have taken into account the next .NET
thunderstorm. But now, in the calm of the storm's eye, we all realize we
need some direction regarding 
ADO.NET
. What's the future of it? To answer
this, let's start looking and weighing what we have and what we lack today.
For several reasons, 
ADO.NET
 is a better and richer model than ADO. But are
they functionally equivalent? The answer is no. To come to a total parity
between ADO and 
ADO.NET
, at least a couple of top issues have to be tackled:
the schema object model (ADOX) and server cursors support. Today, you have
only workarounds to manipulate the database schema from within .NET
applications. You can issue provider-specific queries and work in read/write
manner or you could read (only) schema information through the .NET OLE DB
data provider and the adapter's GetOleDbSchemaTable method or use COM
Interop Services to call into the COM-based ADOX object model. In the
future, 
ADO.NET
 will provide read/write access to table schema information
using a .NET object model based on DataSet, Table, Column and Constraint
objects.
Server cursors are not supported in 
ADO.NET
. For positioned updates and long
lock operations you can use multiple SQL statements and keep connections and
transactions open. However, a new bunch of ad-hoc objects are on their way.
The principal of these objects is the ResultSet--a provider-specific
scrollable and updateable server cursor. Each .NET data provider will be
exposing its own implementation of such an object in much the same way .NET
managed providers expose data readers and data adapters today. A ResultSet
will work similarly to the writing counterpart of the today's reader
objects. Such a 'data-writer' object would allow you to position a record,
read/write its value, and persist updates.
So much for the parity, but what would be a key advantage of the 
ADO.NET
object model over ADO? To make a long story short, what arguments can we
poor programmers use to convince our bosses to give the green light to the
adoption of 
ADO.NET
? Well, in 
ADO.NET
 version 1.0 there's a little, but
potentially explosive, feature that will be significantly expanded in future
versions. I'm talking about typed DataSets. A typed DataSet is a .NET class
built atop the DataSet class. It inherits all the methods, events, and
properties of a DataSet and also provides strongly typed methods, events,
and properties. Each table and column becomes a child object of this
data-specific object and can be accessed by name instead of using ad-hoc.
A typed DataSet does not give you more programming power per se. It improves
the readability of the resultant code and when used within Visual Studio
.NET, activates the IntelliSense technology and line auto-completion. In
addition, with a typed DataSet type mismatch errors are caught at compile
time rather than at run time. Creating typed DataSets today requires the use
of a command-line tool (also buried in the Visual Studio.NET interface) to
generate a new class from an inferred XML schema. Aside from strongly typed
access to data, a second key concept of typed DataSets is that you expose
information inside a DataSet as stand-alone objects. These same concepts
will be expanded a bit in the next versions of 
ADO.NET
 to spawn a vivid new
software entity: the Object Space. The object space is an evolution of the
typed DataSets--basically the necessary code is dynamically generated at run
time. The object space contains objects to store, update, and query data,
realizing a neat separation between business logic and data access code.
Relationships and constraints are still supported and automatically
enforced. A new object query language--that has explicit recalls to
XPath--completes the cast. From the programmer's standpoint, you create only
an entry point to the object space and then move within the space using a
common and generic set of methods. Schema and code that proves to be
necessary for further operations is generated on the fly.
There's still a lot you can expect from 
ADO.NET
 and the path to effective
data access seems to be paved with the best intentions to make it as smooth
and productive as ever. In this final chapter, I've quickly outlined the
future developments of 
ADO.NET
. But 
ADO.NET
, as it comes out of the box in
.NET Framework 1.0, is already a big deal. Enjoy, but stay tuned!
Read Chapter 6: "Advanced Data Reporting" from our Book Bank.
http://www.devx.com/devxpress/gurl.asp?i=1X3359375X54177
Buy from Amazon at 30% off ($34.99 instead of $49.99)
http://www.devx.com/devxpress/gurl.asp?i=1X3359375X54178