When developing a relational database model for an application one can create for example an entity-relationship model, e.g. using MySQL Workbench. Although documenting those models using UML class diagrams is also very common. Both methods can be seen as standard way to go when making up an architecture for a project.
Question: what is the standard way to go for no-SQL database models?
I want to design a model for MongoDB and/or ElasticSearch which are basically arbitrary JSON stores. But I need to document at least the fields and the "relations" to each other to give a reference structure.
Is there any tool (diagram language?) existing? I looked into the documentations and found no hint for an answer. I'm aware of text files and know that one could simply write a text file with an example JSON. But I'm looking for a little bit more sophisticated and polished solution.
Any ideas or standards here?
Moon Modeler for MongoDB is a tool for visual definition of noSQL structures. It allows you to draw diagrams similar to entity relationship diagrams - with nested types/embedded documents.
Related
I am curious to know that if Entity framework can create tables in other databases besides MS-SQL ??
Moreover, is there any provision to create XML schema through EF ?
Under the hood Entity Framework uses providers that are specific for different databases. So it depends on a provider whether EF can create tables or not. However, I haven't heard about providers that do not have this possibility. The easiest way to be sure is to write a simple program with a few lines of code.
As to XML schema. Are you asking about using XML files instead of database as the storage for your data? If so, again it depends on the provider. If you want you can theoretically create one that will use XML files. However, I haven't tried to do so and I don't think that it is a good idea. There are technologies that fit here better (see this question).
I'm just starting to learn EF and now readind about Code First workflow. From what I gather, you would design your objects first and then the database would be created based on those objects. I can't seem to see the good in this. Why would you let your database schema be dictated by the hierarchy of your objects? Would you be able to optimize your database using Code First?
Also, as I have not read far enough yet, does Code First fully support DBMS features (indexes, triggers, sp, etc)? I ask as I've read in some articles that this is what most preferred (Code First). I have seen something about Code Second which is from what little I've read, I think is much better (existing database, but code centric development?), but maybe I'm missing something or haven't yet read enough and you guys can clear those things up. Thanks.
The capabilities of code first are the same since you have the same ability to express all the features of EF manually in your code. The main difference is that you don't use a designer to generate your EF code. This offers some benefits since you can decouple your entity classes from the EF context. The main benefit of this is that you can use plain old c# classes that aren't necessarily tied to EF if you decide to switch to another orm down the line.
The downside of course is that you have to hand code the entire model.
Keep in mind that you don't have to generate the database from your code. You can code against an existing database.
I have recently started getting familiarized with NoSQL (HBase). I am definitely a noob.
I was investigating about ORMs and high level clients which can be used on HBase and came across a few.
Some ORM libraries like Kundera are providing SQL like data query functionality. I am finding this a little counter intuitive.
Can any one help me understand why we would again need SQL like querying if the whole objective was to move away from it?
Also can anyone comment on your experiences with ORMs for HBase? I looked at a few of them from http://wiki.apache.org/hadoop/SupportingProjects and started looking at Kundera.
Another related question - Does data query with Kundera run map reduce jobs internally?
kundera or Spring data might provide user friendly ORM layer over NoSQL databases, but the underlying entity model still has to be NoSQL friendly. This means that NoSQL users should not blindly follow RDBMS modeling strategies but design ORM entities in such a way so that all NoSQL capabilities can be used.
As a thumb rule, the kundera ORM entities should be designed using query-first strategy where first the queries need to defined so as to create primary keys and also ensuring that relationship model is used as minimal as possible. Querying on random columns and full scans should be avoided and so data might have to be replicated across entities for reducing multiple entity look ups. Also, transactions management needs to be planned. FYI, kundera does not support transactions(beyond single row TX supported by Hbase/Cassandra).
Reason for using Kundera:
1) If looking for SQL like support over HBase. As it is build on top of HBase native API, so it simply transforms these SQL queries in to corresponding GET or PUT method calls.
2) Currently it support HBase-0.20.6 only. Kundera-2.0.6 will enable support for HBase 0-90.x versions.
3) Kundera does not do sometihng out of the box to provide map reduce over SQL like queries. However support for such thing will be provided in Kundera-2.0.6 by enabling support for Hive native queries only!
It is totally JPA compliant, so no need to learn something new. It simply hides complexity at developer level with very minimal effort.
SQL like querying is for developement ease, quick developement, less error prone and reusability ofcourse!
-Vivek
I use Zend_Db in some project, I discover Doctrine there is a while but never actually used it.
What are the advantage of Doctrine over Zend_Db ? What are the benefits to use Doctrine ?
By the way, is it easy to use Doctrine with Zend Framework 1.10.7? Integration and use with the other component ? As it doesn't seem to exist a Doctrine Adapter
Thank you
Doctrine is an ORM. It's meant for persisting a rich domain object model to a database and allow querying effectively while maintaining the results as objects. Zend_Db comprises an implementation of the table and row data gateway design patterns, which provide a simple scheme for querying a single table and manipulating its rows. That makes Zend_Db a kind of a lesser cousin of Doctrine, with the latter vastly more powerful and useful while also more complex and resource intensive. If you have a rich domain model with a lot of interrelations, Doctrine is your solution to managing all the complexity. For simple CRUD on simple tables, by all means go for Zend_Db.
You don't need an adapter for Doctrine, you just use it. Several classes in Zend Framework integrate readily with Zend_Db, though - such as validation based on database row existence - and you'll have to cook up your own equivalents. It will take some work but it's not a complex task, and you may be able to find some implementations readily available on the net.
Trying to wrap my head around the best approach in modelling a database when we are using Entity Framework 4 as the ORM layer. We are going to use asp.net mvc 2 for the application.
Is it worth trying to model using the class diagram modeller that comes with Visual Studio 2010 where you graphically configure your models into the EDMX file and then generate out the database structure?
I have run into a bunch of non trivial issues and for complex many to many mappings or multi primary key entities the answer is not that obvious even after poking around a while with the tools.
I figure its easy at this point to give up and start modelling the DB using real, working DB modelling tools and then try to generate out the EDMX from the database, rather than trying to do the model first approach.
It's really a matter of preference. If you are comfortable in SQL server that's probably the best place to start. But if you are more of a C# programmer, it's sometimes easier to start in the EDMX designer, make the model and then ask it to figure out what the database should look like.
Of course if you do go model first you'll still need to go in to SSMS and add indexes and maybe rename some FKs and tables more to your liking. Then you can bring the model back up to date with an Update from Model.
Modelling inheritance is also something you'll need to do in the designer, but again you can either do it in SSMS or in the EDMX designer. For inheritance I mostly prefer SQL first because there is the explicit decision as to what form of inheritance you want - per hierarchy, per class, or per concrete type.