[std.database]
Marco Leise
Marco.Leise at gmx.de
Sat Dec 3 09:57:42 PST 2011
Am 03.12.2011, 13:07 Uhr, schrieb Dejan Lekic <dejan.lekic at gmail.com>:
>
>> One thing I notice is everyone seems to only be Targeting Relational
>> Databases. Any plans to support Flat, Object, Key Value, Hierarchical,
>> or Network Model systems? It would be nice to have at least
>> specification support for systems like membase(memcache), hbase,
>> vertica, csv files, and similar systems.
>
> That is the reason why I originally suggested std.database is perhaps a
> wrong place to cover all use-cases.
>
> Second, there will be native (pure D) interfaces to various data sources,
> and also there will be bindings to C libraries with the same purpose.
>
> Third, handling of relational databases will not be the same as with non-
> relational.
>
> Fourth, SQL - there are many people who like mister C.J.Date think SQL is
> not good for working with relational databases. So I would strongly
> recommend separation of SQL from the rest because there are other query
> languages around, including C.J.Date's "Tutorial D".
>
> IMHO, the center building block should be the DataSource. DataSource (or
> DateSet perhaps is a better name) should be ANYTHING that can be
> represented
> as collection of tuples.
>
> Examples:
> 1) directory list - it is a data source representing the content of a
> file-
> system directory.
> 2) result of an SQL query
> 3) *ANY tuple* is a DataSet with a single tuple as an element.
> 4) *ANY collection* can also be seen as DataSet (if the key is part of
> the
> tuple)
>
> With this kind of abstraction std.data (that is my preferred name for
> this
> package) would probably be the most powerful data abstraction layer I
> have
> seen so far. With std.loader we can even have pluggable drivers for
> various
> types of DataSources ...
>
> Regards
>
Sounds interesting until you talk about collections. This puts more
interfaces on every collection (Range + DataSet), is that good? On the
other hand I remember how nice the latest GUI toolkits work with data
sources for table views, edit boxes, labels and so on. So I also see a
long term benefit of this in terms of software architecture. Maybe you
should do a sample implementation we can evaluate. Some CSV, two different
container types, the directory listing and how it works with the data set.
Also what effect would this have on how foreach iterates different
collection types?
More information about the Digitalmars-d
mailing list