Related
I am confused about the database I should choose, since the application I am doing will store and handle large amounts of data, I think SQL Server will be better than MySQL. Any recommendations?
Both platforms SQL Server and MySQL can handle small and large software projects, so you should anticipate similar performance from both, provided the database designer and programmer are familiar with the right way to optimize queries and code.
Structured query language (SQL) is the language of relational databases. Several database platforms use SQL, but a slight variation on it—each tend to have a slightly different syntax. Microsoft SQL and MySQL are two of the most common database platforms on the web. Once you go with one, it can be very difficult to switch to the other. That’s because the database platform you choose will end up being the core of your dynamic content moving forward. It stores, secures, and retrieves all the data for your applications.
It’s an important decision to make, and will likely hinge on a few things. If you’re having a hard time deciding which one is right for your project, here’s a look at some similarities and differences between the two, SQL and MySQL.
THE BASICS
Whether you want to store, retrieve or edit your data—the way dynamic websites and applications perform nearly every request a user makes—SQL is the language of choice for relational databases. On the surface, both Microsoft and MySQL look similar:
They both give you the ability to host several databases on one
server.
They use tables to store data.
They have primary and foreign key constraints.
They use indexes to sort data and speed up performance, and they both support desktop and web applications.
SQL Server is slightly older than MySQL. Microsoft SQL Server was introduced in 1989 and MySQL was introduced in 1995 as an open-source project. Since both of them have been in production for years, they both have a firm foothold in the market. MySQL runs on either Windows or Linux, typically as a part of a LAMP environment. SQL Server runs on Windows, and is usually a part of a Windows environment.
Both platforms handle small and large software projects, so you should anticipate similar performance from both, provided the database designer and programmer are familiar with the right way to optimize queries and code.
Microsoft SQL Server vs. MySQL: Similarities
Both Microsoft and MySQL are relational database platforms, so they have several similarities. Most developers specialize in either one or the other, because although they appear similar, the way they work in the underlying architecture is very different. Here are some similarities, which make it somewhat easy for a database developer to work on both platforms efficiently, even if they specialize in only one.
Scalability: Both platforms allow you to scale as your business grows. You can use both for small projects, however should these projects take off to an enterprise-level, they can still support millions of transactions a day.
High-performance: A database is your application’s backbone. It stores your all of data, so you need a database that can return data in less than a second. Both platforms can handle this type of high-performance speed.
Tables: Both platforms use the standard relational database table model to store data in rows and columns.
Keys: Both platforms use primary and foreign keys to establish relationships between tables.
Syntax: Syntax between the two database platforms are similar, although there are some minor differences across different CRUD (create, read, update, delete) statements.
Web-based popularity: Aside from Oracle, Microsoft SQL Server and MySQL are the most common databases used for web applications. When you sign up for hosting, you typically get a choice between MySQL databases or SQL Server.
Drivers: You can find connection drivers for almost any popular language on the web, so you can easily connect to both platforms without writing complex code.
MICROSOFT SQL SERVER VS. MYSQL: DIFFERENCES
While the two platforms are similar in the interface and basic relational database standards, they are two very different programs and operate differently. Most of the differences are in the way they operate in the background, and these differences are not seen by the average user. As long as the database performs well, it can be used with your project. However, it’s still important to know these differences because they’ll play a huge role in your developer’s choice platform.
Native compatibility: You can use either database with both Windows and Linux projects, but MySQL works natively with PHP and MSSQL is mainly used with .NET. It makes integration simpler if you stick with MySQL for PHP and MSSQL for Windows projects.
MyISAM and InnoDB: Both of these engines are configurations for MySQL and allow the developer to perform very different design and programming. With MSSQL, you create a database and don’t specify different engines.
Cost: SQL Server is generally expensive to run, because you need licenses for the server running the software. MySQL is free and open-source, but you’ll pay for support if you need it.
LINQ: With MSSQL, you can set up your entity framework classes in .NET and get started with LINQ queries. With MySQL and .NET, you need to download third-party provider tools.
IDE tools: Both platforms have IDE tools, but you need the right tool with the right server. MSSQL uses Management Studio and MySQL has Enterprise Manager. These tools let you connect to the server and manage settings and configurations for security, architecture, and table design.
WHICH ONE SHOULD YOU USE?
The database you use usually depends on the hosting environment you choose. Linux hosting providers usually offer MySQL. Since MySQL is open-source and free, you can have as many databases as you need. You can have 10 of them to support 10 different projects if need be.
Because SQL Server costs money for licenses, Windows hosts will give you one MSSQL database and you must pay for additional ones. Overall, this makes SQL Server more costly than MySQL. However, SQL Server works natively with .NET applications, so it’s the choice for software that runs on a Windows server or desktop. The development tools are free, but the production environment is not free.
The best way to determine the right platform is to first post your project in the marketplace and discuss your requirements with a few developers. You will get different opinions and preferences based on the developer’s area of expertise, but most Windows developers work with MSSQL and Linux developers work with MySQL. You should decide which environment you want to target, and then you can get a clearer idea of which platform is right for you.
Source
sql-vs-mysql-which-relational-database-is-right-for-you
Both Mysql and mssql can handle big data. but mysql is better in this ways
security: if You choose Mssql u'll host on windows server which is considered less secure.
NB: SQL Server 2017 available on Linux. but most hosting companys haven't updated it
Cost: hosting Companies will give little free database space on Mssql compared to mysql.
example in godaddy MSSQL 1 database x 200MB(economyPlan) 2 x 200MB(deluxe) Unlimited x 200MB(ultimate).
MySQL databases 10 x 1 GB(economy) 25 x 1 GB(deluxe) Unlimited x 1 GB(ultimate).
If your not sure, then you probably don't have alot of experience. I would suggest you start with MySQL assuming you have Linux available. It is much more forgiving and allows you to quickly re-start the database if you mess something up. SQL Server is almost impossible to stop and restart without rebooting the windows server, which is a long process and could bring your whole system down for 10 minutes or more. A Mysql restart in linux takes 2 seconds or less.
Sql Server is MUCH more expensive but it has many more tools and features.
If you are looking to use this as a backend to get more development work, SQL server DB's generally get more money, and it is used more in corporate world. Microsoft has extensive tools and addins with SQL server, much more than my sql.
It is interesting to note that SQL Server can connect to MySQl to allow you to write queries in SQL server that directly query Mysql (this is called a linked server) , but the reverse is not possible. So in the future, you could split up your databases. AS a general rule of thumb, if you have website traffic coming in AND backend processing, create multiple databases, even if they are on the same server, so you can move one of them off to another server when your the database gets busy.
I've been trying to specialize into the MS SQL server technologies, but my job has required me to understand more MySQL recently. Has any MS SQL DBA or developer had to do this, and if so, what were their biggest challenges? At the moment, for me:
Lack of decent IDE
No easy ETL tools like ssis
As an IDE for designing MySQL DBs I'd suggest MySQL Workbench.
I think one of the biggest problems migrating from MSSql to MySQL is saying good bye to transactions and hello to autocommit.
Here's a little comparison between MySQL 5.0 and MSSql 2005 (a little outdated...)
and here's what MySQl says...
The biggest difference between the two technologies in my opinion is that the database engines that are under the hood are quite fundamentally different.
This has implications, particularly for enterprise class systems, as the performance tuning techniques and best practice design principals that you use to optimise and design a SQL Server platform will not necessarily translate to MySQL.
If you already have a solid understand of the SQL Server database engine then I would look to develop this level of understanding with MySQL, starting off by looking at the different database drivers that can be used to drive the MySQL Engine such as INODB and MyIsam etc.
The fundamentals of relational database management of course remain the same, i.e. you are working with tables, indexes and keys etc. so you are not starting from the absolute beginning here. If you are familiar with using T-SQL to navigate your database structures and tables then porting this to a MySQL command prompt is quite a smooth transition.
You may find GUI tools such as Navicat to be to your liking if you frequently use SQL Server Management Studio (SSMS) to administer your databases.
To my knowledge, there is no integrated ETL platform such as SSIS to compliment MySQL, as it focuses solely on the core database engine. Microsoft SQL Server is considered an Enterprise database suite and so incorporates additional components that complement the database engine, such as Reporting Services, Analysis Services, SSIS and Notification Services etc.
I hope this helps you on your quest to work with a new technology. Learning something new is a great problem to have.
Cheers, John
The last I checked there were no UNIQUEIDENTIFIER data type in MySql. That could become a hard part in migration since lots of applications are written based on vast use of Guids.
I'm not following of the development of MySql, could be that this datatype is already there.
Someone asked me this the other day, and I couldn't think of a good answer. Platform portability is completely irrelevant to the project.
In fact, Jet has some features that SQLite does not, namely foreign keys.
So can anyone think why SQLite should be used instead of a Jet database?
Contrary to what other people are saying, Jet is not dead and far from it: ACE is the new version of Jet and it's pretty robust and backward compatible.
Both SQLite and Jet/ACE have their strengths and weaknesses and you need to get more information about the specific points that are important to you and your application.
In either case you can redistribute the engine.
Jet/ACE is a bit more integrated and supported out of the box in MS tools and Visual Studio.
Jet/ACE has more granular locking, which may be important if your app allows multi-users or needs multi-threaded access to the database.
Jet/ACE has more features in terms of what you would expect from a database (joins, unions and complex queries).
Jet/ACE has a simple migration path to SQL Server, so if your database needs become big, you could move to SQL Server fairly easily.
SQLite is cross-platform, so if your app needs to be ported to Linux/Mac under Mono then SQLite is a better choice.
the SQLite engine is tighter so redistributing may be easier.
datatypes are quite loose in SQLite.
SQLite has more liberal redistribution rights (since you can basically do whatever you want with it).
People who say that Jet corrupts databases are stuck in 1995.
In the end, unless your application has some very specific requirements that are pushing the boundaries of either database engines, then it probably doesn't matter which one you chose.
Just use the one that easiest for you to include in your project.
SQLite is superior to Jet for the major reason that SQLite is ACID-compliant whereas Jet, unfortunately, isn't. If data integrity is an issue, SQLite offers a much more "robust" platform for your data storage requirements. See "SQLite Is Transactional" and "Atomic Commit In SQLite" for more details.
SQLite does indeed lack a few features (such as foreign keys), however, these are primarily due to SQLite being specifically developed as being an extremely small and lightweight database that is also serverless.
The serverless aspect of SQLite is also a major benefit over Jet in that nothing needs to be installed on the machine that will run your database. For example, I have used SQLite in an ASP.NET web application and all I needed was the SQLite DLL (in this case is was the excellent System.Data.SQLite drop-in replacement) in my application's "bin" folder, and my database in the application's "App_Data" folder. I could then upload these files to my webhost, and it all "just worked". This is without having to actually install or register anything on the target machine.
A small dowside of SQLite is due to the database being file-based. Database writes will lock the entire database file rather than a specific row or table, whereas Jet will offer you a more granular level of locking. Another small issue, based on the same file-based reasoning, is concurrency, however Jet itself does not offer a high level of concurrency either.
This is still a question that comes up from time to time. I'm considering all the pros and cons for both right now for a new project. I write a lot of financial applications that deal with money values so one of the most important "pros" for Access/JET/ACE/whatever-they're-calling-it-today (I just call it Access) is its strong types. Don't underestimate the power of having strong types when you're dealing with money - Access is the only single-file database I've seen with support for a money/decimal type that can store REAL money values.
One of my main retail products uses SQLite as a backend and I can tell you that I've had virtually no problems with it deployed even in the craziest situations. SQLite is definitely designed to be single-user but I have a LOT of customers using it over SMB. You do have to write checks into your software to check for return values of SQLITE_BUSY when running queries but if you wrap that up with an auto-retry it "just works".
There are only a few reasons I'd choose Access over SQLite - one is data types. If I'm ever writing software that has to do math on money values (tax, etc), I'll use Access. The only other compelling reason to use Access is an upgrade path to SQL Server. Since I've never used SQL server in my life (and don't plan to), it's not a big deal.
In the end, both are extremely robust databases - I wouldn't hesitate to use either in a production environment. Just remember to use the right tool for the job and sometimes that means a database server (PostgreSQL has treated me right over the last 13 years, that's for sure!).
We used Jet for a long time and recently switched over to SQLite. Why?
1: When a database gets anywhere near 2 GB or with frequent use, it becomes corrupted in Jet eventually. This has caused us a lot of grief! This has not been fixed in Jet or ACE, though Microsoft has a separate tool that can supposedly fix the database files.
2: Microsoft deprecated Jet years ago, in favor of ACE, but if you read the details, Microsoft itself says that ACE is NOT a replacement for jet, and really wants you to use SQL Server instead.
3: Jet is no longer a standard part of Windows, but part of Microsoft Office, though you can download and install the distributable. However, you can not have both the 32 and 64-bit engines installed at the same time. If you have Office 2007 32-bit installed, and you try and install the 64-bit ACE engine, it tells you need to uninstall Office 2007 first.
So for these reasons we just decided enough is enough. Installing SQL Server is not a solution because it is a big complex invasive install and not very portable.
Our C++ software directly supports SQLite via the sqlite3.c file, and it works very well. I have implemented antive interfaces for OCILIB, Oracle, SQL Server, MySQL etc and this was one of the easiest. It is also much faster than Jet and the resulting files maybe a third of the Jet size. We do have some VB6 and VBA and .NET code that also need to use our database files and for that we use the SQLite ODBC driver (just Google it). Works well.
SQLite works fine in both 32 and 64-bits. And if you read up on it you will see it is seriously tested and amazingly stable. It also supports more standard SQL and is closer to Oracle/SQL Server than Jet is.
Jet is no longer supported. SQLite is also easier to install since it's one dll that can easily be packaged with your app. Using SQLite also can prevent vender lockin, just because language or cross platform portibility isn't a concern now doesn't mean it won't become one later. For more on Jet's retirement see
http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine
Cost is not an issue. If your frontend is built in something other than MS-Access, users of the application do not have to pay any fees to have the Jet drivers installed. Visual Studio would include those drivers during your build (At least the pre .NET versions did.).
I'm guessing you have no personal preference and are equally skilled in development in either environment. If your users have already MS-Access licenses and they would like to be able to write their own reports (Oh, God forbid any non-hacker attempting such a tremendous feat!), use Jet.
SQLite is the new Jet. Even if cross-platform is irrelevant to you, it may not be to your customers. Using Jet locks them into Windows and to a no longer supported DB, neither of which are good things. And SQLite works with just about any development environment out there.
Jet is known for having strange corruption issues, so I tend to stay away from it in general.
You can certainly create foreign keys in SQLite, and as of SQLite 3.6.19 foreign key constraints have also been added.
Off the top of my head, it's free and cross platform; but more important... do you think it is more stable and scalable that Jet/MS Access/.mdb? Will it be longer lived that its successor (ACE/.accdb)
If it is being used by more than just a couple people, I don't bother with Jet. I go straight to MS-SQL (even the free version of it). It's just not worth the pain of a corrupt DB (which Jet is known for - although maybe they fixed it - I don't want to be their test case though).
If you program well in Python, Pearl, Lua or many other languages, SQLite would be the natural choice.
I've used both and I've found MySql to have several frustrating bugs, limited support for: IDE integration, profiling, integration services, reporting, and even lack of a decent manager. Total cost of ownership of MSSQL Server is touted to be less than MySQL too (.net environment), but maintaining an open mind could someone point out any killer features of MySql?
I've used MySQL in the past and I'm using MSSQL lately but I can't remember anything that MySQL has and MSSQL can't do.
I think the most killer feature of MySQL it's the simplicity. For some projects you just don't need all the power you can have with a huge system like MSSQL. I have an UNIX heritage and find the simple configuration file like my.ini a killer feature of MySQL.
Also the security system of MySQL is much less robust but it makes the job right for most of applications. I believe MySQL it's killer itself from this point of view, and should stay that way, letting young users being introduced to RDBMS with a simple view first. If your project gets big enough that you are considering switch to a more robust system, then MSSQL can pop as a possibility.
That's what happened to me.
The only thing I can think of, off hand, is locking. SQLServer has traditionally had poor locking strategy that has tripped many people up.
You should use what you prefer, ultimately. Its not as if MySQL is not good enough to compete with MS SQL, eg. Slashdot uses MySQL, so its hardly got problems with high-scalability performance.
Its killer feature though, is that it is free - you can deploy as many of them without worrying one fig about licensing issues. That's more important for the spread of software than anyone could imagine.
(TCO is a difficult thing to calculate - and is advice only ever given from paid consultants and other vested interests. Ignore that. MSSQL is expensive and MySQL is free.)
About 6 years ago I developed a custom e-commernce website using ASP and MySQL for the database. At the time MySQL was clearly a better choice than MSDE which had built in throttling which concerned me enough to use MySQL. Also the difference in coding between using MySQL and MSDE/SQL was not that different or much of a concern.
Now all these years later I'm trying to get the code converted to .NET and even after purchasing commercial MySQL drivers from CRLab. I found that, as you hinted, the IDE integration is just not up to par.
I will say that MySQL is doing a great job even with our database tables approaching 4GB. So when I switch to MSSQL I have to go ahead and get SQL Workstation or higher ($$$), and not use SQL Express which has a 4gb limit.
All of my experience has changed the way I develop new websites. Now, unless it is expected to have a lot of traffic. I use VistaDB and then upgrade to SQL Server if needed. VistaDB is syntax and datasource compatible with SQL Server. And the best part is it is only a single file for the database and a dll for your bin folder.
That's my two cents based on my personal experience with using MySQL in ASP and now .NET.
I work with MSSQL, MySql and PostGres regularly (using .net, java and PHP). One of my favorite things about about MySQL (esp. compared to MSSQL) is the ease with which you can run and restore full database backups.
MSSQL's model of using .bak files is really ugly and time-consuming (topic for another post.) But if you want to do somethign like automated testing, or automated build processes (that include building a db from scratch), MySQL can be a bit easier to deal with.
A few other points:
The management tools have gotten a lot better since the early days.
If you are interested in transactions, constraints, etc.. be sure you are defining your tables to use the InnoDB storage engine (instead of MyISAM which is designed for speed.)
I do miss MSSQL's schema generating tool, but I think there are equivalent tools out there.
We've used a Linux database server and a window's web server (for .net apps) with great success.
If you are using something like NHibernate or some other non-MS data abstraction layer, the case to look beyond MSSQL is stronger too...
Three points to consider; unfortunately the first two are contradictory:
1) .NET and MySQL were not designed to interact with one another, and there is no official support from either side. You're invariably going to encounter issues trying to use them together.
2) If portability off of Windows may ever be an issue (much .NET code runs quite nicely on other platforms via Mono), you'll want to avoid locking yourself too deeply to MSSQL. That doesn't mean not using it, but being careful that you don't rely on its particular quirks too much.
3) TCO is just a buzzword. It's complete nonsense when it's calculated by anyone other than you. Nobody can make such a calculation and honestly claim that it has any relevance outside their particular environment. There are too many factors, most of which have absolutely nothing to do with things like tool availability.
I've been using the community version of MySQL for alsmost 99% of my project. I like MySQL is that I can deploy via Xcopy and is powerful compare to other "xcopy-able" database server. I also wrote a wrapper to start and stop MySQL & Apache (like LAMP), but with my own implemetation and addon capability
MySQL probably has a lower TCO, since administration and configuration is more simple and straightforward than the Spaghetti GUI that MS SQL makes you do most of the configuration through, having to dig through hundreds of obscure properties dialogs to accomplish even basic administration tasks.
There is one area where MS SQL clearly excels over MySQL in my experience:
Integration with other technologies. MS SQL allows you to replicate back and forth with Oracle and MySQL databases, and provides SSIS for executing scheduled data transformations from other database servers.
There may be others, but I don't have experience with them.
I've worked on a variety of systems as a programmer, some with Oracle, some with MySQL. I keep hearing people say that Oracle is more stable, more robust, and more secure. Is this the case?
If so in what ways and why?
For the purposes of this question, consider a small-medium sized production DB, perhaps 500,000 records or so.
Yes. Oracle is enterprise grade software.
I'm not sure if its really any more stable that mysql, I haven't used mysql that much, but I dont ever remember having mysql crash on me. I've had oracle crash, but when it does, it gives me more information about why it crashed than I could possibly want, and Oracle support is always there to help ( for a fee ).
Its very very robust, Oracle DB will do virtually everything it can before breaking your data, I've had mysql servers do really weird things when they run out of disk space, Oracle will just halt all transactions, and eventually shutdown if it can't write the files it needs. I've never lost data in oracle, even when I do stupid things like forget the where clause and update every row rather than a single row, its very easy to get the database back to how it was before screwing up.
Not sure about security, certainly Oracle gives you lots of options for how you are going to connect to the DB and authenticate. It gives lots of options regarding which users have access to what, etc. But as with most things, if you want to take security seriously, then you need an expert to do it. Oracle certainly has a lot more to lose if they don't get security right. But, as with all things there has been exploits.
If nothing else, just consider this... When Oracle stuffs up, they have customers who are paying $40k per CPU (if they are suckers and pay list price) license + yearly maintenance fees.. This gives them a very strong intensive to make sure the customers are happy with the product.
For a small database, I'd seriously recommend Oracle XE well before mysql. It has the important features of mysql (Free), its dead easy to install, comes with a nice web interface and application framework (Application Express), if you DB will happy run on a single cpu, 1gb ram and 4gb data, then XE is the way to go IMHO.
Mysql has its uses, many many people have shown that you can build great things with it, but its far behind oracle (and SQL Server, and DB2) in terms of features... But then, its also free and very easy to learn, which for many people is the most important feature.
I've had Oracle create a corrupt database when the disk ran out of space. It's hard to debug, uses loads of resources and is difficult to work with without seriously skilled DBA's holding your hand. Oracle even replaced system binaries (e.g. gcc) in /usr/bin/ when I installed in on an occation.
Working with PostgreSQL, on the other hand, has been much more pleasant. It gives readable error messages and acts in a more understandable way if you're used to work with open source *nix systems. It's quite easy to set up replication, thus making your data fairly secure.
A 500K record database can probably be run on your mobile phone. Seriously, it's so small that both Oracle XE and MySQL will be more than sufficient to manage it.
for smallish DBs (a few million records), Oracle is overkill
you need an experienced DBA to properly install and manage an Oracle system
Oracle has a larger "base overhead", i.e. you need a beefier machine to run Oracle
the "out of the box" experience of Oracle used to be atrocious (i haven't installed an oracle system in years; no idea how it currently behaves), while mysql is very nice
Oracle is a beast that really needs DBA knowledge. I concur with those who say 500k records are nothing. It's not worth the complexity of Oracle if it's simple numeric/text data.
On the other hand, Oracle is extremely efficient with blobs. If each of your records was a 100MB binary file, you'd need a fortune to run it on Oracle (I'd recommend a 3-node RAC cluster with a good SAN).
I have a project that sends data (~10M rows, 1.2GB of data) to three different databases, 2 Oracle and 1 MySQL. I haven't had problems working with either system, nor have I seen any major advantages on either side. If you're in a place that already uses Oracle for other projects, adding on one new database shouldn't be too much of a problem, but if you're thinking of setting up a new database server and don't have anything in place already, MySQL will save you the money.
Oracle Enterprise assumes that there is an Enterprise to support it, ie, a real Oracle DBA. A novice (but competent) DBA should be able to secure MySQL much more easily than Oracle, just because Oracle is inherently more complex. Of course, Oracle has the Enterprise monitoring tools beyond what MySQL currently features (as far as I've seen) but the DBA needs to be able use them to be effective.
Such a small database as you describe could be handled by most anything so I can't see that Oracle would be warranted unless the infrastructure was already in place. Both have replication, transactions and warm-backups so either would serve well.
The answer depends entirely on how you configure each DBMS.
Both are capable of handling 500,000 records many times over.
Oracle is a lot beefier. Many of its features would only be looked for in a larger enterprise or high-performance setting. They're mainly features to do with scaling, replication and load balancing.
For small DBs, consider SQLite. For small-medium, look at MySQL or PostgreSQL. For the largest, look at MSSQL, Oracle, DB2, etc.
Edit: Having read the other answer, I'll add that if your data is really, really critical, you'll want a replicated setup and you'll probably want to look to one of the big DB providers for something like that.
If you can sacrifice potential (exceedingly rare) data losses and would prefer improved performance, look at some of the lighter-weight options.
It's true that Oracle is a beast.
It is also true that Oracle is widely considered the most secure major database.
The problem is that Oracle's devs don't appear to grasp critical security consepts. Oracle is the least secure database server on the market (According to independent security researchers)
http://itic-corp.com/blog/2010/09/sql-server-most-secure-database-oracle-least-secure-database-since-2002/
MySQL is actually fairly secure according to these researchers. I don't know much about the tools available for it. What's most amusing about this research is that the same people who would call Microsoft SQL server a toy would have their data stolen by attackers that MSSQL would thwart because they are using a beast that has a terrible security model rather than a "toy" that is secure.
I'm using Oracle/SQL Server/MySql for different applications and site
No Database beat can Oracle in many different area, but it's the most database that require deep knowledge for the administration.
and if you found a problem with oracle, may spend few times to solve it even with good DBAs guys.
You can go with MySql for 500K or millions of records, it's more light than other DB, and require zero administration work, and will not take a lot of your computer resources, I always have it in my development PC, and never had faced any serious problem with it.
I would require you go with MySql or PostgreSQL if you don't need the advanced featuers of Oracle.