I want to know that the distributed database system Bigtable is object oriented?
No. It is "a sparse, distributed multi-dimensional sorted map"
(source: http://en.wikipedia.org/wiki/BigTable)
No. It is a rather odd beast - see Wikipedia.
I recommend Google's own research paper on the subject. Good read.
Related
Which from the well-known key/value stores has also the transaction support? We just need to interlace operations in transactions and rollback from time to time.
In case anyone stumbles on this in the future.
FoundationDB is fully ACID
Looks like foundation db has gone and this isn't relevant anymore link has been updated to Wikipedia
Personally, I'd recommend using REDIS. I've used it for a number of different applications and it's solid, fast and has a great community around it.
And it fully supports transactions: here's information on REDIS Transactional Support
I'm not very knowledgable about KV databases, but Berkeley DB springs to mind.
Some time ago i was reading an article about new MS DBMS technology. It's some kind of OLAP but on the fly. This technology can bind to data flows and then provide a real time aggregation. So the question is "what is it's name?". I need such a technology now but can't remember it's name... Or maybe there are some similar technologies?
Are you referring to PopFly? LINQ? Reactive LINQ?
What about this site:
(M Language): http://msdn.microsoft.com/en-us/data/ee460940.aspx
or this one:
(Quadrant): http://msdn.microsoft.com/en-us/data/ee477952.aspx
Regards.
I think you was reading about powerpivot
The problem is no more actual...
My intuition says that ontology engines like Triplestore or Seseme are going to be slower to query than a DB, but is that really the case? What is it that would make them so much slower?
Basically, the answer is 'yes'. This is due to the fact that many Ontology engines use an RDBMS data model behind the scenes to manipulate the ontology. But if you happen to find a thorough engine that does not rely on RDBMS, then it needs benchmarking to find out.
Hope this helps! -- etamar.
According to the Wikipedia article object relational mapping:
is a programming technique for
converting data between incompatible
type systems in relational databases
and object-oriented programming
languages
I thought an ORM also took care of tranferring the data between the application and the database. Is that not necessarily true?
EDIT: After reading the answers I don't know if it's possible to choose a definitively correct answer to this question since perhaps it is subjective to some degree. On the one hand it is true that the ORM per se may not perform the transfer of data but rather JDBC or some other similar technology. On the other hand, the ORM is the actor that is responsible for delegating this task to JDBC and for that reason can be thought of as being "in charge" of the transfer.
The article is referring to the concept of object relational mapping, rather than any software implementation of it, such as Hibernate, which indeed does what you mentioned (possibly delegating the job to other mechanisms).
Either way, it's a collaborative encyclopaedia, so you can always edit that article if you think you can make it more clear.
The transfer of data is typically handled by a lower-level mechanism such as JDBC in Java.
Does anyone know of any design patterns for interfacing with relational databases? For instance, is it better to have SQL inline in your methods, or instantiate a SQL object where you pass data in and it builds the SQL statements? Do you have a static method to return the connection string and each method just gets that string and connects to the DB, performs its action, then disconnects as needed or do you have other structures that are in charge of connecting, executing, disconnecting, etc?
In otherwords, assuming the database already exists, what is the best way for OO applications to interact with it?
Thanks for any help.
I recommend the book Patterns of Enterprise Application Architecture by Martin Fowler for a thorough review of the most common answers to these questions.
There are a few patterns you can use:
Repository Pattern
Active Record Pattern
I personally would hate to work with a database without an ORM. NHibernate is preferable but iBatis is also an option for existing databases (not to say that NH can't handle existing databases).
In general, the best way for OO applications to interface with a relational database is through an ORM; while this isn't a design pattern per se, it's a type of tool that has a specific usage pattern, so it's similar enough. Object Relational Mapping (ORM) tools provide a mapping between a database and a set of objects in memory; usually, these tools provide means for managing things such as sessions, connections, and transactions. A good example of an ORM that works fantastically well would be Hibernate (NHibernate on .NET).
In my experience it is best to have no SQL statements at all (most ORMs will allow that), and it is best not to have any knowledge of connection details (connection string, etc). Even better if you can have the exact same piece of code working with any major db vendor.
POEAA has a wealth of knowledge on the issue if you intend to roll your own.
Everything you will identify by googling for DAL describes a design pattern. Seems like standing in the middle of the forest and asking to see a tree. There are dozens if not thousands.
Here's a quote from a book I'm reading to start with for looking for resources.
... it is impossible to discuss ORM without talking about patterns and best practices for building persistence layers. Then again, it is also impossible to discuss ORM patterns without calling out the gurus in the industry, namely Martin Fowler, Eric Evans, Jimmy Nilsson, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, the last four of whom are known in the industry as the Gang of Four (GoF). The purposes of this chapter are to explain and expand some of the patterns created by these gurus and to provide concrete examples using language that every developer can understand.