When using a database like Cassandra, Kundera imposes limitations consistent with the underlying database. The documentation doesn't make clear, however, whether these limitations also apply to RDBMS's used under Kundera.
In other words, does Kundera provide access to all the functionality of the underlying Hibernate implementation when working with an RDBMS?
Related
I want to use aws for hosting a django application and use aws rds for database purpose. The application is kind of blog like system.
I am not able to decide which RDS I should choose over MySql or Postgres? Both price wise and performance wise according to aws pricing policy.
This can be very broad and may be opinionated , I would try to keep it short as i read it somewhere:
MySQL would be very good for any CMS Site as it works very well with it and MyISAM tables are quite nice here.
From What I read where PostgreSQL does better than MySQL:
Multi-application databases
Advanced data modelling
What Advance Data Modelling means is that PostgreSQL is far more mature at doing complex data modelling than MySQL is. It has a very mature extensible type system, a wide range of procedural languages, and a great deal of flexibility in how these languages can be plugged into existing queries.
If that wasn't enough, the fact is that you can essentially build your data model in PostgreSQL based not only on what information you are storing but what information is commonly derived from what you are storing. This makes things like not-first-normal-form actually sane to use where they are needed. Add collections and multiple inheritance in table structure and you have a very sophisticated data modelling platform, this blog would help you understand it better.
Besides the content management system market, MySQL's other major market is in applications where data is not expected to be exposed to more than one writing application at a time. This leads to a significant difference in handling data validation, etc.
In PostgreSQL validation is always equally strict. If the app expects special error treatment it had better call functions or casts to handle this explicitly.
MySQL however places the application in charge of defining the data validation rules.So while PostgreSQL allows the relational and object-relational interface to serve as a public API, it is essentially intended largely to be a private API for applications in MySQL. This is a huge difference and not readily understood by many people trying to make the choice. This leads to major differences in application design.
MySQL is a data storage and reporting solution for your application.
PostgreSQL is a data centralization, modelling, and reporting solution
for your organization. The two are remarkably different.
Now coming to Second Question based on pricing as you can see from MySQL Pricing Page and PostgreSQL Pricing Page MySQL is bit cheaper than PostgrSQL , reading on the answer you can make informed decision what would be best for you.
Hope this Helps!
I'm gonna offer you a 3rd option: Aurora - try it. It's cheaper than those 2 and is MySQL compatible.
This article may be of help to you when deciding.
For simple blog-like thingie I'd go with MySQL (or Aurora MySQL compatible version)
For data-critical and highly relational solutions I might also consider Postgres (Aurora)
We have a classified website. I read few things but still not got a solid reason to choose between these.
My requirement is to just create user, listing and manage these. These are paid listings so monetary transactions would be there.
As per my research (https://www.mongodb.com/compare/mongodb-mysql) I found that mongo db has edge over other options except for complex transactions. What are complex transaction in this context? Any specific examples?
What factors should I consider before choosing one. I have experience with My SQL and Entity framework so its more appealing to me now but are these really bad for scaling when compared with mongo?
Feel free to suggest any other good performance option apart from these choices.
There is a vast difference between mongoDB and MySQL or SQL Server.
MongoDB is a NoSQL database meaning it is schemaless and doesnot follow CODD Rules of RDBMS whereas MySQL/SQL Server is relational Database.
Each are meant for different use cases. As per mongoDB doc
Why use MongoDB instead of MySQL?
Organizations of all sizes are adopting MongoDB because it enables them to build applications faster, handle highly diverse data types, and manage applications more efficiently at scale.
Development is simplified as MongoDB documents map naturally to modern, object-oriented programming languages. Using MongoDB removes the complex object-relational mapping (ORM) layer that translates objects in code to relational tables.
MongoDB’s flexible data model also means that your database schema can evolve with business requirements. For example, the ALTER TABLE command required to add a single, new field to Craiglist’s MySQL database would take months to execute. The Craigslist team migrated to MongoDB because it can accommodate changes to the data model without such costly schema migrations.
MongoDB can also be scaled within and across multiple distributed data centers, providing new levels of availability and scalability previously unachievable with relational databases like MySQL. As your deployments grow in terms of data volume and throughput, MongoDB scales easily with no downtime, and without changing your application. In contrast, to achieve scale with MySQL often requires significant, custom engineering work.
What are common use cases for MongoDB?
MongoDB is a general purpose database that is used for a variety of use cases. The most common use cases for MongoDB include Single View, Internet of Things, Mobile, Real-Time Analytics, Personalization, Catalog, and Content Management.
When would MySQL be a better fit?
While most modern applications require a flexible, scalable system like MongoDB, there are use cases for which a relational database like MySQL would be better suited. Applications that require complex, multi-row transactions (e.g., a double-entry bookkeeping system) would be good examples. MongoDB is not a drop-in replacement for legacy applications built around the relational data model and SQL.
A concrete example would be the booking engine behind a travel reservation system, which also typically involves complex transactions. While the core booking engine might run on MySQL, those parts of the app that engage with users – serving up content, integrating with social networks, managing sessions – would be better placed in MongoDB
As there is no concept of join in MongoDB so if you want to store data, either you have to create a hack to store data in two table(although it is expensive cal to join in MongoDB) or you have to store data as a single document,, making your document too complex.In these cases MySQL has upperhand.
If I am using JPA with MongoDB and later if I would like to change database to MYSQL, how easy to do switch from MongoDB to MYSQL?
Reason why I am asking this because I understand that MongoDB is non relational and MYSQL is relational database. So at the time of changing database do I need to make lots of changes in Entity classes?
First thing that must be said is that JPA was designed around RDBMS only, and so some aspects (e.g query language, joins) are not suited to "other types" of datastore. Consequently it is all down to how a particular implementation handles things.
I know that with DataNucleus JPA the impact is very small, in terms of configuration needed. Typically if an RDBMS-only configuration is seen when using MongoDB it simply ignores the setting, hence it is largely transparent.
I'm a long-time user of the DevExpress XPO library. It has many great features, but there are a few weaknesses:
When saving an existing object, all properties are sent in an update query; changes are tracked on a per-object basis, not per-property.
Optimistic locking is done on a per-object basis, rather than per-column.
When an optimistic locking exception occurs, no context is provided describing the nature of the conflict; your only real response is to fail the operation or reproduce it and try again in a loop.
LINQ support for XPQuery is very weak (at least in 8.1, which we're using). Thus, you're often forced to use XPView, which is not type-safe, or XPCollection, which can be returning columns you don't necessarily need.
After reading about how LINQ to SQL implements optimisting locking and handling update conflicts, I was sold! I like how it implements column-level optimistic locking and doesn't need to add a column to the table. Being able to inspect and handle the exact nature of conflicts is great. And the fact that they track per-column changes should make its update queries much more efficient.
Of course, I haven't yet used LINQ to SQL in real applications, so I don't know it compares in reality. Also, I'm unclear on if it has analogs for some of the features we enjoy with XPO, such as:
Automatic schema updates (we believe in object design driving database structure rather than the reverse, and this greatly simplifies software deployment)
Two options for how inheritance is implemented (same-table or one-to-one table relationships)
Support for in-memory storage (though I suppose that we could substitute LINQ to Objects in our unit tests)
Storage provider customization (that allowed us to add NOLOCK support to our XPO queries)
We're going to be doing an exploratory partial migration where we will be temporarily using the two ORMs for different parts of our code. Have any of you had real-world experience with both XPO and LINQ to SQL? How do they compare in practice? Specifically, do you know of any features that LINQ to SQL lacks that would provide challenges to a code migration?
Oh, and should I even care about LINQ to Entities? It looks far more complicated than anything we need.
I'm sad that I didn't get any answers from the community, but here's my thoughts so far. I've had a chance to try out LINQ to SQL and ADO.NET Entity Framework for a while on different projects, and I feel that ADO.NET Entity Framework would better fill our needs. As far as the XPO-specific features I was hoping to keep:
Automatic schema updates will have to go once we convert. It's a minor annoyance, but there are a few benefits to maintaining this separately.
ADO.NET Entity Framework has a lot of data mapping options; the different inheritance models appear to be supported.
For in-memory storage, I'm still unsure how well-supported this is. There appears to be a SQLite ADO.NET provider that is compatible with the Entity Framework, and SQLite can do in-memory storage, so in theory the unit tests could use a different connection string specifying the in-memory database. Hopefully it's that easy; otherwise, writing unit tests will be pretty hard to do without a lot of work (abstracting out a repository interface, etc).
I haven't looked into provider customization yet. I've tried to architect the system such that we won't have as much data shared among services as before, so maybe we won't need all those WITH (NO LOCK) statements that I needed in previous systems. Or maybe SQL Server 2008 has improved its locking mechanisms so that we won't encounter the same locking issues.
So you did migrate your application from XPO to Linq2Sql, didn't you? I've been playing with XPO as part of XAF too, honestly I prefer Linq2Sql/EF to XPO but since it is tightly coupled in XAF so I don't have other choice. We're going to use XAF to speed up UI implementation of a our product, I think XAF does its work quite well, but I'm really worried about XPO.
Thanks,
I am working on a project that is going to use CouchDB for flexible storage of documents. The requirements of my system are a neat match for CouchDB for storage.
BUT
My question really boils down to this:
Should I keeop using ActiveRecord and MySQL as well ... there are a raft of handy Plugins that are all readily available for use with ActiveRecord (such as authentication and access control). Just wondering if the advantages of leveraging existing plugins is worth the extra management overhead and possible integration issues (working across disparate datastores).
It is not uncommon to have to deal with several persistent stores in a single application. A very common approach is to use a relational database that stores paths pointing to files that are stored in a file system.
So you might think as CouchDB as a special "file system" for a special part of your data model.
Also, in larger applications, multiple stores and complex physical architectures are quite common, so don't be shy of using more than one persistent store for your models.
You can use both; Some models can still be ActiveRecord, and others can be CouchDB.