I'm a long time slimserver user with an original squeezebox. Today I
started to upgrade from 6.3.x to 6.5.x, only to note in the Makefile
(FreeBSD ports) that MySQL is now a requirement.
Some mistake, I thought, it must be! But apparently not... although if
someone can assure me that 6.5 and above will NOT require MySQL, that
would be a big win.
Assuming that the developers indeed have made a dreadful mistake and
made MySQL a requirement, I'd like to know... WHY?
The data model and processing requirements for a tool like Slimserver
do not outgrow the abilities of so-called 'embeddable' databases such
as sqlite. Convince me otherwise, if you can.
Best read the archives of the developer list. The thing that really did in SQLite IMHO was its poor performance and high memory consumption, but IIRC there were some problems with growing into more advanced SQL as well.
In my professional capacity I have shunned MySQL for years, but I'd be
willing to rant on about this requirement even if the developers had
standardized on a database engine which I prefer (Postgres, even Oracle
or SQL Server). Including yet another big chunk of software raises other
issues of security, compatibility and upgrades; yet another process on
the box; another thing to manage and potentially backup.
So my question is... why?
In my professional capacity I frequently deal with people who are married to one technology choice or another. Since our product is closed source, I have to tell them that they need to chose their marriage or our product, because they can't have both. In this case, SlimServer is open source, so you're perfectly welcome to fire up vi or emacs and DBI into something else. I'm sure that the results would be welcomed on the wiki or as a patch. Of course, this represents a high opportunity cost, but if you really care, the option is there.
I don't really care. I've worked as an administrator and lightweight devel/QA with MySQL, SQL Server, PostgreSQL, and Oracle... they all have their issues, and they all have their positives. Unfortunately the SQL standard is almost completely non-standard, so supporting more than one in a given application means a lot of "if I'm on this database, use X, but this other one needs Y, and the third one needs Z." That means poor performance. At the end of the day, the database support decision is kind of like the implementation language decision; you either grin and bear it, or you give up, because supporting more than one is not feasible. That's just my opinion though :)
--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional
_______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
