Another alternative that is also open source and freely available is Postgres, which differs significantly from MySQL in terms of the "options" and "extensions to 'vanilla' SQL" that are offered. Different folks have different opinions about the relative merits of Postgres and MySQL/MariaDB, and both camps have some sensible reasons for their preferences (e.g. because of the particular extensions offered by one or the other, the relative ease of maintenance and back-ups, etc.).
Both RDB systems are well documented and fully capable of handling the dimensions you're looking at, but when you write SQL schemas and queries for one, there's a non-null (and non-trivial) chance that you'd have to change a number of details (in both schema definitions and production code) if you later decided to switch over to the other. So, if you're still at the planning stage, and have the choice, you'll want to check out both and "choose wisely" for your particular application.
Both systems are fully supported by DBI and DBD modules (and as a result, all the supplemental DBI-related modules work equally well with both systems). To the extent that your sense of "fastest and easiest to use" is a matter of being sure that perl scripting can be sensibly compact and efficient, there's no cause for worry with either DB.
Of course, to the extent that "fastest and easiest to use" could mean "ability to get something running with the minimum of study and planning," things could also go remarkably badly with either system. Knowing (vs. not knowing) how and when to use additional, non-default indexes, how and when to use transactions and commits, etc., can lead to orders-of-magnitude differences in performance, no matter which database engine you choose.
In reply to Re: mySQL base with a lot of records
by graff
in thread mySQL base with a lot of records
by natol44
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |