BigTable is among the so-called column-oriented databases: http://en.wikipedia.org/wiki/Column-oriented_DBMS
Check out: http://www.hypertable.org/ http://en.wikipedia.org/wiki/BigTable Cassandra: http://cwiki.apache.org/confluence/display/CSDR/Index<http://cwiki.apache.org/confluence/display/CSDR/Index> And this: http://en.wikipedia.org/wiki/Document-oriented_database http://couchdb.apache.org/docs/intro.html http://labs.mudynamics.com/wp-content/uploads/2009/04/icouch.html ---------- Is there anyone who can summarize the strengths of the various 3 types? The first two are obvious in some way to me: pervasive (current) existence of SQL DBs, and need to manipulate existing data, ability to in small to medium (and large???) scale take advantage of open-source SQL servers; BigTable - the increasing presence of Google as a desktop computer replacement - mail, documents, blogs, now application serving --- it's the big, open (in terms of data) "database"... Not clear what the implications / advantages (disadvantages) of using open-source (e.g. your own data pool) solutions would be here. On Sun, May 3, 2009 at 5:34 PM, dlypka <dly...@gmail.com> wrote: > > Even though there are existing widgets, do they handle the specific > issue > of working with the CRUD Error framework? i.e. is class INPUT > considered to be a widget? > I suspect we need a variation of CRUD that generates widgets > internally instead of INPUT instances etc, > > On May 3, 5:51 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > we have widgets already. Look into gluon/sqlhtml.py for examples. The > > only thing missing is a repository for third party widgets. It would > > be great is somebody were to take care of that and maintain a > > repository. > > > > Massimo > > > > On May 3, 4:11 pm, dlypka <dly...@gmail.com> wrote: > > > > > > > > > I think it is a great idea to be started the sooner, the better. > > > > > Plus, I also recommend creating a "wig2py" (widget 2 py) for GUI > > > Controls similar to the idea of ASP.NET controls > > > to solve the problem of using custom forms with CRUD. So I believe 2 > > > critical web2py framework projects needs to be taken on ASAP. > > > > > By the way, Microsoft has recently released their 'Entity Framework' > > > (which I use every day at work now) > > > and so bascially there is a Kind of DAL choice in their architecture: > > > ADO.NET style > > > or > > > Entity Framework style > > > > > So if they can do it, so can web2py.. > > > > > On May 3, 4:05 pm, Yarko Tymciurak <yark...@gmail.com> wrote: > > > > > > the question of non-relational DBs is an interesting one, and > increasingly > > > > will become so in the years to come. > > > > > > I think DAL is structured to make web2py apps portable - allow you to > run > > > > your design without regard to backend storage. Clearly, that is > biased > > > > towards relational databases which are prevelant today. > > > > > > But non-relational data stores are increasingly becoming prevelant - > big > > > > tables being the perhaps most influential example, but also Apache > has > > > > interest in several: Hadoop, couchDB.. > > > > > > Clearly, the playing field is still expanding in this area, and it is > > > > exciting times. > > > > > > The question is not about stoping progress - the question is what > path to > > > > take to lead / follow / influence progress. > > > > > > Since DAL imposes little enough on you for portability (a goal), it > is > > > > unique in being able to map to _some_ BigTable functionality. > > > > > > The question is how to procdeed. > > > > > > I think DAL should follow the objectives which Massimo set out; > > > > extensibility may be useful for Relational use, but peripheral. What > > > > remains interesting is central portability in the domain of > relational data > > > > stores; GAE is at the edge of that. > > > > > > A perhaps more interesting suggestion is to have a DAL project which > writes > > > > a non-relational data store abstraction, and begins to put the > structure of > > > > things like BigTable, ... I don't know what others would fit into the > "same > > > > kind of" class, or what a useful union for a non-relational DAL would > be - > > > > perhaps Hadoop, CouchDB, MongoDB, etc. > > > > > > But to do that would require people who are familiar with the broader > uses > > > > of those other dbs, and interested in abstracting to create a new, > > > > non-relational DAL: DALnr?. > > > > > > For starters, I suggest a useful excercise might be to consider the > > > > interfaces within web2py, and how to make a DALnr that starts as > SPECIFIC to > > > > one backend, to gain familiarity with it, and to work out the details > of how > > > > this changes interfacing w/ web2py --- this excercise would free > someone to > > > > explore the non-relational backend more thouroughly, and would second > be a > > > > refactoring driver for web2py DAL integration... eventually leading > to the > > > > ability to choose which KIND OF DAL your project uses. > > > > > > Perhaps some unification between these two - so that applications can > be > > > > portable accross both types - will emerge, and this would be useful. > > > > > > But I think the first step is to cleanly, intentionally separate the > two > > > > kinds of back ends and see where that leads. > > > > > > What does everybody think? > > > > > > - Yarko > > > > > > On Sun, May 3, 2009 at 12:38 PM, dlypka <dly...@gmail.com> wrote: > > > > > > > When I evaluate a database framework, the first thing I look at is > the > > > > > field types. > > > > > Right now I see web2py supports these types: > > > > > > > •db.Field(name, 'string') > > > > > •db.Field(name, 'text') > > > > > •db.Field(name, 'password') > > > > > •db.Field(name, 'blob') > > > > > •db.Field(name, 'upload') > > > > > •db.Field(name, 'boolean') > > > > > •db.Field(name, 'integer') > > > > > •db.Field(name, 'double') > > > > > •db.Field(name, 'time') > > > > > •db.Field(name, 'date') > > > > > •db.Field(name, 'datetime') > > > > > •db.Field(name, db.referenced_table) # reference field > > > > > > > My vote would go to extending the web2py types to include some non- > > > > > relational types and > > > > > the first one would be that GAE ListProperty type.,.. > > > > > Perhaps there needs to be some type of type-extension feature. NET > has > > > > > it. > > > > > So then the developers can develop and plugin their own types. > > > > > And there can be a pass-thru or 'raw' query mode which will pass a > > > > > native query down to the actual database handle. > > > > > > > We can't stop progress... > > > > > > > On May 3, 12:31 pm, Tim Michelsen <timmichel...@gmx-topmail.de> > wrote: > > > > > > Kless wrote: > > > > > > > I'm more interested into a framework backed by a non relational > db, > > > > > > > mainly MongoDB [1]. By that reason I discard Django, and to > Pylons > > > > > > > because it hasn't a plugin system that lets reuse/share > applications. > > > > > > > > > Is web2py ready to use non-relational databases? > > > > > > > > > [1]http://mongodb.org/ > > > > > > > > I'd be interested in: > > > > > > *http://www.pytables.org > > > > > > *http://www.gaia-gis.it/spatialite/ > > > > > > > > Regards, > > > > > > Timmie- Hide quoted text - > > > > > > - Show quoted text -- Hide quoted text - > > > > - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
