SQL DB for *BSD

6502

6502

Is there any major RDBMS compatible with BSD license and widely used under FreeBSD? I read a list of all existing RDBMS in Wikipedia. SQLite is too simple for complex projects. MS SQL has Linux version but not FreeBSD. Same for Oracle DB. It seems only PostgreSQL is powerful, popular, still in development, and is not GPL. I prefer MySQL/MariaDB but read discussions that closed-source application cannot use it because of GPL.
 
The two 400 lbs gorillas of full-function SQL databases that are free (as in beer) are Postgres and MySQL. Postgres is distributed under a version of the Berkeley license. Both MySQL and MariaDB are distributed under some version of the GPL (MySQL is also available as a commercial supported product under a proprietary license from Oracle). All of them can be used in closed-source applications, except if the source code of MySQL is modified, the modifications to it will have to be distributed. There is always this rumor around that one can not use GPL software in closed-source or commercial applications, and that rumor is mostly false. The easy way to understand it: If one simply uses GPL software, without modifying or distributing it, then one's own source code does not need to be open-sourced. That is similar to Linux (the kernel) in general; there is lots of non-open-source commercial software on Linux.

There are other options if one doesn't need full SQL functionality. I'm very fond of Berkeley DB (a.k.a. bsddb or SleepyCat). No SQL, but very fast and efficient, and easy to develop for. Well, at least if you don't need transactions, then it gets a little hairy.
 
IMHO, the selection criteria for which RDBM to use for a given project would not be simple vs. complex.

Do you really need a DB backend as a server, i.e. running as a daemon listening on local domain and/or IP sockets? If yes, then go for MySQL or PostgreSQL. In case this is actually not needed you want to consider SQLite again. While the others can be restricted to answer requests on the local domain sockets only, 1 single mistake in the configuration files and you open a armageddon like security breach in your setup.

Do you want to program the frontend yourself or use 3rd party frontends? In the first case, the license actually matters. AFAIK, most of the MySQL frontend libraries are GPL and that means you need to open your frontend code to the public, or at least hire a bunch of advocates doing a code review and then would swear to you under the threat of penalty of death that your code and its usage of the GPL’d library does not violate the license. Honestly, I would simply use PostgreSQL’s libpq for the frontend to a server side DB backend, which besides the license has the benefit of being much better documented. If you don’t need a server, as I said already, I would go with SQLite, which is in respect to SQL almost feature complete.
 
balanga said:
I doubt whether it is GPL but that's not a bad thing. It is Open Source AFAIK.
Click to expand...
Put yourself in his shoes. He wants to develop closed source software and wants to do it with as little legal hassle possible.
Enter the BSD clause 2 license. You don't have to give anything back ever. Good Indemnification. Spelled out clearly.
Free to use however you see fit (Just don't strip out the copyrights in source).
 
obsigna said:
IMHO, the selection criteria for which RDBM to use for a given project would not be simple vs. complex.
Click to expand...
I sort of disagree. Always use the simplest solution that will do the job. The trick is to know how to even measure "simple versus complex". For me, working at home on my little home server and home improvement projects, it is nearly always my own time. If I can use pre-cooked technology to solve a problem instead of having to implement the solution myself, that is nearly always advantageous. Similarly, if I can use a tool that is described in a 100 line man page, that is much better than using a tool that requires 3 big books to read before you can start using it. Other people will have other definitions of simple versus complex, depending on their needs.

Do you really need a DB backend as a server, i.e. running as a daemon listening on local domain and/or IP sockets.
...
Click to expand...
That is also a very good question.
The other very good question is: Do you actually need SQL? If your schema is complex (dozens of columns), and you don't know ahead of time what type of queries will be done, then you really do need SQL. In particular if your data is valuable for things like analytics and business intelligence a.k.a. data mining. For example, you are recording a whole variety of measurements (water pressure, water well level, temperature, rain, whether the heater in the house is on, how much propane is left in the tank, outdoor lighting, sunlight intensity ...), then I can see a human wanting to measure correlations or check crazy things, and that's the realm where SQL queries are perfect.

On the other hand, if your schema is really simple, only 2 or 3 columns, then you'll never have to use SQL to query it. For example, you're recording network bandwidth as a function of time, every 5 minutes: there is nothing you can do with SQL that you can't do much easier with awk, or a 5-line perl/python/ruby/... script. For that, a NoSQL database is probably much easier to use. And if you don't need an external server (only one program uses the database at a time), then a simple non-transactional key value store like Berkeley DB is probably perfect.
 
You must log in or register to reply here.
Back
Top