I have one primary key (Integer) on my entities, but I also have a UUID on those entities that I do a lot of searches on. I am wondering if it is possible to make that UUID a key as well, so that Hibernate (or whatever) does not have to fetch the entity from database each time, but can check its cache first instead?
I'm not sure about Hibernate. But if you use EclipseLink in the 2.4 release there is support for cache indexes on non-id fields. Then any query using the UUID will be able to obtain cache hits.
See,
http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching/Indexes
Related
I want to improve performance by not doing search query where i know that data will be unique.(In my app every new user will require default data. Which will be created in server side where there is no need to do unique test.)
#UniqueConstraint is only used for schema generation. JPA doesn't do any search for unique constraints at runtime.
I have been searching on EF Core documentation, if adding .HasIndex() on your entities mappings would bring any benefits on a DbFirst scenario, and I couldn`t find anything.
I have this 20yo DB that has all the necessary tables and indexes created, and I am mapping some tables to query them using EF Core. I wonder, what could be the benefits of mapping the indexes on a DbFirst scenario where you would never update the tables schema via code? Does it affect the way EF generates the SQL queries?
None. HasIndex would only apply to creating indexes for code-first/migrations. You don't need to map indexes for EF to generate or optimize the query.
I do recommend after introducing EF to a project to record/report on the most common queries executed to determine whether there are new indexes or adjustments to existing indexes that might benefit your application's performance. (I.e. included columns)
I have created a SQL DB and examined the integrity. Now I wanted to put these tables in mongoDB, and I've kept it in the mapping rules. Table = collection, row = doc, and so on.
But how does one set about following in mongoDB:
create table pruefen
( MatrNr integer references Studenten on delete cascade,
VorlNr integer references Vorlesungen,
PersNr integer references Professoren on delete set null,
Note numeric(2,1) check (Note between 0.7 and 5.0),
primary key (MatrNr, VorlNr));
DBRef, I've tried but is not a foreign key replacement.
And if the application is to take over as it would look then?
MongoDB has no cascading deletes. When your application deletes data, it is also responsible for removing any referenced objects itself and any references to the deleted document. But usually when you use on delete in a relational database, you have a case of composition where one parent object owns one or more child objects, and the child objects are meaningless without the parent. In that situation, MongoDB encourages embedding instead of referencing. That means that you create an array in the parent object, and put the complete child documents into that array instead of keeping them in an own collection. That way they will be deleted together with the parent, because they are a part of it.
While keeping more than one value in a field is an absolute no-go in SQL, there is nothing wrong with that in MongoDB. That's because the MongoDB query language can easily work with arrays and embedded objects. You can even create indices on fields of sub-documents in arrays, so you can easily search for objects which are embedded in other objects.
When you still want to reference objects from another collection, you can either use a DBRef, or you can also use any other unique identifier (uniqueness is one of the few things which can be enforced by MongoDB. To do so, create an unique index with the createIndex command). But MongoDB does not enforce consistency in this case. You can create DBRefs which point to non-existing ObjectIds and when the document the DBRef points to is deleted, nothing will happen. The application is responsible for making sure that when it deletes a document, all documents which reference it are updated.
Constraints can not be enforced by MongoDB either. It can't even enforce a specific type for a field, due to the schemaless nature of MongoDB. Again, your application is responsible for making sure that the data it puts into mongodb is following specific specifications. When you want to automatize this, there are object-relational mapping frameworks for MongoDB for many programming languages available.
To wrap it all up: MongoDB is not as "smart" as SQL databases. It doesn't do much on its own. It does what it is told to do by the application, not more and not less. But that's the reason why it's so fast (no expensive consistency checks) and flexible (no database modifications necessary to implement new features).
One of the great things about relational database is that it is really good at keeping the data consistent within the database. One of the ways it does that is by using foreign keys. A foreign key constraint is that let's say there's a table with some column which will have a foreign key column with values from another table's column. In MongoDB, there's no guarantee that foreign keys will be preserved. It's upto the programmer to make sure that the data is consistent in that manner. This maybe possible in future versions of MongoDB but today, there's no such option. The alternative for foreign key constraints is embedding data.
since mongoDB does not support foreign keys, I've read that you can use for DBReF. Now I want to like to test this relationship.
The 2 collections are
db.professor.insert({"_id": 1122, "Name":"Heinrich","Rang": "C3","Raum":"D123"})
db.assistent.insert({"_id": 2244,"Name":"Schmidt","Fachgebiet":"Neuronale Netze","Boss":{"$ref":"professor","$id":1122}})
First question, but it should not be at the reference the wrong id may assume or. And if I entries with the correct ID $ id how can I test the reference?
Background is that I examine the data integrity features mongoDB!
Does anyone have sources on mongoDB and data integrity
MongoDBs inter collection data integrity is zero. This is not a bug in the way MongoDB works nor is it desired that this behaviour should change.
Not having inter collection data integrity is one of its core features as a NoSQL ( http://en.wikipedia.org/wiki/NoSQL ) product which this behaviour is commonly associated with (that being said it doesn't have to).
Of course this has nothing to do with general data integrity but cascading and referencing of relationships server-side.
A DBRef ( http://docs.mongodb.org/manual/applications/database-references/ ) is no different to just saving a ObjectId into your document. The only real difference is that it is a object of objects which also store a property to house the collection name. There is nothing special about the DBRef except that it comes pre-bundled with the MongoDB driver for most (if not all) languages as a helper to allow you to query the other row in your application.
Many do confuse the purpose of a DBRef however I assure you that there is nothing truly special about it.
So there is no check to see if you put in the wrong ObjectId and there is no cascade on the relationship and there is no "foreign key" behaviour in MongoDB.
Any and all relational integrity comes from your application and its ability to work in such a manner that prevents any problems within your data. This applies to both inserts and cascades of pseudo relations.
Considering these brief facts about MongoDB your test is almost useless, if you wish to test the data integrity of a relational model you should use a relational database.
How can I implement a foreign key like relationship in Mongo DB?
hiya see this: MongoDB normalization, foreign key and joining && further http://shop.oreilly.com/product/0636920018391.do ===> http://books.google.com/books/about/Document_Design_for_MongoDB.html?id=TbIHkgEACAAJ&redir_esc=y
MongoDB doesn't support server side foreign key relationships,
normalization is also discouraged. You should embed your child object
within parent objects if possible, this will increase performance and
make foreign keys totally unnecessary. That said it is not always
possible, so there is a special construct called DBRef which allows to
reference objects in a different collection. This may be then not so
speedy because DB has to make additional queries to read objects but
allows for kind of foreign key reference.
Still you will have to handle your references manually. Only while
looking up your DBRef you will see if it exists, the DB will not go
through all the documents to look for the references and remove them
if the target of the reference doesn't exist any more. But I think
removing all the references after deleting the book would require a
single query per collection, no more, so not that difficult really.
Edit update
http://levycarneiro.com/tag/mongodb/
levycarneiro.com/tag/mongodb [quote] So you create 4 collections: Clients, Suppliers, Employees and Contacts. You connect them all together via a db reference. This acts like a foreign key. But, this is not the mongoDB way to do things. Performance will penalized. [unquote]