I'd have thunk that the Microsoft database folks would have been more aggressive in oodbms ten years ago and more, but I guess they were already busy, and I'm pretty happy with what they've delivered. and maybe we don't want the back end recognizing special operator for classes after all, let the front-end language LINQ or something do that.
The ORM middle tiers can do the swizzling and mapping and whatnot. we have a subclassing pattern to relational table design. OTOH, most SQL Server practitioners, at least, use integer identities very copiously, very nearly achieving that object identity for each entity that oodbms would seem to require. These are hard to do in an industrial-strength database like sql server, because the semantics of these user-defined classes would have to be specified in gruesome detail to the engine, to the compiler and optimizer, if not the storage mechanism. and, arguably first-class status for user-defined types, aka classes, and private or overloaded operators for them all. an oodbms should support whatever this year's list of OO primitives might be, including at least inheritance. oodbms arguably has as a primitive an object identity for each entity (id-entity, get an oodbms should be able to "persist" an entire web (directed, cyclic graph of n-dimension), requiring the "swizzling" of memory pointers. I do agree that we ought to be looking for new alternatives to the SQL model of data - but to replace SQL I think we need to be It is precisely the advantages of declarative query languages like SQLĪnd the relational algebra that have made SQL and the relational model so predominantly successful over the alternatives. However, if you want to use an imperative programming language for data access then I don't think that's something which there is likely to be a lot of support or demand for. Arguably if it was more relational then it might come closer to the type of features you are looking Of course it's also true that SQL Server is not really a "relational" DBMS because it's based on the SQL model rather than the relational one. The relational model does not restrict the type of data that can be storedĪnd so does not prevent the use of "native" object types (something already achieved in SQL Server through the use of CLR defined types). It means the same thing, ie: support for any data types of arbitrary complexity (including user defined types). There is no fundamental difference between a RDBMS and an "OO" DBMS. I'm a MS guy, that's why I want MS to do it first then it's competitors :) If microsoft added support, it will gain advantage over it competitorsĪnd many many developers will start to use it for it's simplicity and performance. db4o has remarkably large community despite the fact that it's open source, non general purpose embedded db and peopleĪre asking for scallable, multi-threaded server environment.Īs an example, Linq also wasn't demanded by developers, but MS inovated with it, and now it changed the way we work with data. There is no a large community because there is not a product from a big player such as Microsoft, Orale or MySql. Maybe it won't be a perfect solution for all problems, but for most cases, it's the right thing to go IMHO. As I have mentioned above, it has lot's of advantages.
#Difference between oodbms and rdbms pdf code
It is the best RDBMS on the market IMHO, it has perfect integration with it's development tools, which too, doesn't have an equal competitor on the market (don't tell me about java,įor more than 10 years, they couldn't even decide if they should put properties in the language when MS inovated with LINQ, Code Contracts, IntelliTrace etc etc).īut today, in OO world, people want to store their objects nativelly.
You are right, Microsoft made an outsdanding progress regarding Sql Server. Is there someone from MS here to give a clear answer? :)
So this technology is worth a try, the concept of storing data in relational model is almost half a century old. So I think it would be a great move from Microsoft to support OODBMS engine in SQL Server, just like MySql has different engines in one DBMS.įor example, one commercial OODMBS is used in more than 50000 companies, including GSM Providers (working with large, real time data), Airports, Goverment, Military, Science simulations etc. In OODBMS, every class I'll write will be automatically persistent, without the need to write translation code to relational model, or generating hard to customize entities. This object-relational mapping layer like EF and Linq2Sql is almost impossible toĬustomize the way I want. I know, but stil Object-relational mapping has to serialize the object to relational model when this process is absoloutelly useless and expensive in terms of performance.
0 kommentar(er)
