In school, I only learned how to interface with the software that runs the database but not how to build that software. I want to learn how to build the software of a relational database. Is there any resource such as a book, class, webpage, etc. that discusses the architectural features of a relational database and its implementation? I understand that MySQL and Postgres are open source, but I don't have a theoretical understanding, so I feel that examining a repository won't do me much good.
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)
Are there any benefits to using MongoDB for a Node.js application rather than a traditional SQL database such as MySQL, if I'm not planning to have large (>1000 item) collections and am already comfortable with SQL?
MongoDB is schema-less document based database. This means you can insert a JSON object with other nested objects. This can make development easier, especially for prototyping.
For a small project, why not? For a larger project you should do more research. Large or small, doesn't hurt to do the research anyway. You want to consider how your application uses the database (reads vs writes) and how MongoDB scales horizontally, and how it handles failures.
There's a thing called the CAP theorem that defines NoSQL databases. MongoDB is CP. This visual guide shows the relationships between different databases. What is most important to you and your application?
Something else to consider is that most NoSQL databases are not ACID compliant. If you're using MySQL with InnoDB, that can be something significant to give up, depending on your application. For example, transactions might be something you might not want to give up.
Lots of pros and cons. Best thing to ask yourself is: What am I gaining? What am I giving up? There are many things, and it really depends on your use-case.
There are lots of reasons to stick with a simple dbms for a small-scale application. One of them is the widespread availability of cheap hosting services providing MySQL. Another is ease of deployment and maintenance.
Of course, if you're trying to learn to use MongoDB, go for it!
i must design a system which unifies 4 applications, these applications share a lot of information (which at the current system, the information is duplicate in databases).
My first idea was to use a distributed database system in order to avoid all these duplications and the manual synchronization among the systems, the think is that almost everything needs implementation from the beginning (since the database is the heart of these systems) so i don't know if the time/money/implementation combination is the best solution or not.
The technologies that i have in my mind to use:
MySQL Federated Engine to achieve the distribution in databases
CakePHP: 2/4 applications are in CakePHP so i will keep it the same language.
Python: 1 application is in python
Java: 1 application is in java
Will i have any problem with the above languages and Database engine ?
Any ideas, suggestions ?
Any feedback will be appreciated!
You design from the top down. You build from the bottom up.
Databases are the bottom layer. It's the last stage of design, and the first stage of construction. Data modeling, database design, and database administration are fundamental to good data management. And without good data management, the rest of the project is doomed. While the database is going to be what you build first, you need to have a clear idea of what you are going to do with the data. Look at the needs from the top down. you need to do this before you select particular technologies. You may have done this, but just didn't mention it in yuor question.
Unofortunately, databases designed with a narrow scope in mind seems to be the rule today, rather than the exception. Integrating disjoint databases into a coherent unified database (whether it's distributed or not) is far from a trivial task. There will be trivial differences in such things as naming and composition, and non trivial differences in the conceptual data model.
Good luck!
I am building a social network (connections and their connections, messages and locations) and I am a little confused in deciding whether to go with a relational database (MySQL) or a no-sql system (MongoDB) when designing our backend APIs. Does anyone have any views on what to use when?
PS: I am building developer APIs for developers to tap into our system with oAuth. So scalability and performance is also key factor. Rails 3 + Devise (most likely).
This depends largely on which technology you are comfortable with, what exactly do you want to get out of this etc. etc.
Coming back to your question, not all data is relational. So For those situations, NoSQL can be helpful. With that said, NoSQL stands for "Not Only SQL". It's not intended to knock MySQL or supplant it.
SQL or MySQL has several very big advantages:
MySQL is Strong mathematical basis.
Declarative syntax.
A well-known language in Structured Query Language (SQL).
Highly proven and extremely reliable technology. MySQL has been around far more than the oldest noSQL. It's a mature piece of technology. Google Adsense runs on MySQL, Facebook persistent store is MySQL. The examples suggest its reliability.
As a result of being mature technology, people have optimised the shit out of it.
Enormous online and open source community both for support and providing features as opposed to noSQL technologies (look what happened to Cassandra)
In my opinion, all the above questions matter to me when I choose a piece of technology. Hey well, if it's a Sunday evening project that you want to whip up with little real world consequences then do what whims you but if it's slightly more serious then please consider these questions.
SQL hasn't gone away (even in noSQL). It's a mistake to think about this as an either/or argument. NoSQL is an alternative that people need to consider when it fits, that's all.
Documents can be stored in non-relational databases, like CouchDB or even in MySQL (it borders on abuse but still). A Relational database in principle could make a very good NOSQL solution
Check out this hilarious video. This gives a different perspective on this topic :)
I chose MongoDB for my "Social" application because of the flexibility of the schema and scalability/performance. MongoDB has allowed me to adjust my schema without having to make drastic code changes and makes reading/finding data very easy.
I also chose MongoDB as a learning experience. I wanted to know what all the fuss was about with these "noSQL" databases...and now I know why. MongoDB is awesome in my opinion and definitely worth looking at for a Social network that requires scalability and performance. Node.js would also be an excellent choice for the API ;)
neither.
Go with a network/graph database, you will not regret. My current favorite is Neo4j.
http://neo4j.org/
note: Not related to Neo4J
I think the latest version of Neo4J has a sql interface, just in case you would need SQL compatibility. Otherwise, do your crud using their native library. It is very fast.
If you would need to visualize the Graph data, which would be very impressive to show to your boss, use yEd package. To export neo4J to a graphml format, use this:
Convert Neo4j DB to XML?
You could front end your relationships in Neo4J and backend it with a relational db or mongodb. I have seen those hybrid architectures as well.
If you project requires actual relationships between certain objects then MySql will be fine. If you are storing things that typically just have inherent data to them, such as a user with messages to other users, then a document style database, such as MongoDB, makes more sense.
You can do relationships in mongo, but they make a lot more sense in a relational database. But, if most of your data is more inherent of a user then mongo makes more sense.
In your case a document type of scheme makes more sense where each user has a list of connected users and their own personal atributes, ect...
I am new to Ruby and wondering if most people are using the SQLLite db that seems to be the most natural and recommended db to use with Ruby? Or are people using the traditional MySQL db?
What are the benefits/drawbacks of each with Ruby?
Thanks,
Alex
SQLite is used primarily for development purposes only because it is quite simple to setup a database without much frustration, however it is certainly less efficient in terms of concurrency (which is highly likely for web applications) than something like MySQL. So regardless if you use SQLLite in development or not, it is highly advisable to use MySQL (or something equivalent) in production.
For completeness sake, SQLite is also used in "all in one package" software (such as mobile development), in which you can easily bundle a SQLite file with your application.
As stated on SQLite Website:
SQLite is not intended to be an
enterprise database engine. It is not
designed to compete with Oracle or
PostgreSQL.
and
Another way to look at SQLite is this:
SQLite is not designed to replace
Oracle. It is designed to replace
fopen().
In terms of the benefits with Ruby, there really isn't much benefit as libraries/ORMs (i.e. Active Record) really abstract the differences between the two systems to make a consistent access layer in a single wrapper.
SQLITE is cool for desktop applications, mobile applications, and for development :) because it is easy to install and to manage, also it stores all data in one file, which is easy to copy.
But it is a bad choice for production. It doesn't support parallel acces for writing. As bigger file, as slower queries. Problems with scaling. And a number of other problems.
See this topic for more information
https://stackoverflow.com/questions/3630/sqlite-vs-mysql
In rails, you are using ActiveRecord ORM. Many developers are using sqlite adapter for development with ActiveRecord, because it is very easy to setup it.