Captain Splendid's Journal: SQL?

Having had another look at the DB suites tailor-made for the legal profession, I'm even more firmly convinced that I need to roll my own. Neither of the top two products have much presence outside of the Microsoft ecology, which actually makes my life easier as that's a deal breaker for me.

So I'm looking at consolidating our Quickbooks data and the handful of Filemaker DBs into one custom beast, and I could use some feedback.

I feel like I've got both ends of the problem covered, for the most part: I've been working with FM long enough to understand the hard lessons of good planning, user SNAFUs, and all the other good habits you pick when you have literal morons using and modifying your DB. And I'm geeky enough learning new syntax and futzing around with a CLI that I'm not worried about learning curves, but I still have a few questions before heading off in the wrong direction:

• Having looked around, I think I'll be going with mySQL, as it seems like the most ubiquitous and stable of the lot. Anyone want to disabuse me of that notion or pimp their favourites?
• Cross-platform compatibility is a must, as I will always be running a very mixed network. There don't seem to be any issues that I can see, at least with mySQL, but is there anything I should watch out for if I'm intending to view/edit from a variety of OSes?
• Following on from that, and something I'm obviously too stupid to know how to search for: What about end-user GUI? I can happily sit at a CLI doing my job, but that won't work for everyone else. Obviously (to me), the DB should be accessible via browser (this covers the compatibility and end-user experience IMO). Are there some products I should be on the lookout for or I should just get my PHP on?
• mysql Workbench look interesting. Anybody use it? Like it?
• Anything else I might be missing?

MySQL is fairly stable

[WillAffleckUW]

I've been using MySQL on a number of OS and we use it as the internal backend for databases here and for web-faced LAMP interfaces.

It's fine, so long as you don't really ever have a lot of field-level record locking issues, but are mostly record or table based. Haven't ever really had problems with it.

I don't really like PHP, but it does work and so that's what we use.

Admin side or legal side?

[Shadow Wrought]

It sounds like you are doing this on the administrative side of things. I'm assuming this is this for tracking cases, documents created by case, and tracking your billables and spending by case, and that kind of thing. I've used a couple and they had a steep learning curve. DocsOpen back in the late 90's and then some inhouse ones after that built on Access. The only real advice I can give is that your attorneys, support staff, and Admin types will need different screens. I'd also find the most technol

Re:

[Captain Splendid]

will need different screens

You mean privileges ore are you talking about look and feel?

I'd also find the most technologically challenged person at each level and train them on how to use it.

My method is more 'find that person and design it so that even they can't fuck it up'. Similar, but with less training costs.

Also, as I said a while back, I hire for brains, not talent or skills. You can teach skills, but you can't teach brains.

Re:

[Shadow Wrought]

I was thinking that the information going into and out of the system for attorneys is going to be different than your admin types will be using. You don't want to let attorneys change client matter numbers, and you don't want your billing department being able to edit a brief. That kind of thing.

Hiring for brains is the only way to go. Unfortunately budget concerns have us looking one step lower: we avoid hiring crazy. :-)

Good timing?

[tomhudson]

You might want to give it a look-see this weekend. [slashdot.org] Tested under linux (LAMP) and windows (Uniform server - a WAMP) - Runs fine under both (then again, why shouldn't it - you can't get much more bare-bones than that).

You want a database that supports "on duplicate key". It saves a LOT of headaches, so that eliminates postgresql.

My two cents

[stoolpigeon]

You have a few options in the RDBMS category. I'd personally go with one of two - Oracle or PostgreSQL. MySQL can be forced to be decent if you know what you are doing, the other two will take much better care of you right out of the box. My assumption in a system like this is that data integrity trumps speed. And when we say that, they'll be plenty fast anyway. But if you do go with MySQL read up ahead of time on the things you'll need to do to get at least some guarantees that you wont lose data.

Oracl

More cents

[daemonburrito]

There's nothing technically deficient about MySQL. It's definitely the easiest to set up, the most common, has the most web gui admin tools, etc. However, given the way Oracle is behaving, I'm running away from it. I'm afraid the free MySQL is going to get progressively less useful and more buggy, at least. Depending on how long you wish your app to function well, and whether you're going to buy support, this could be a factor.

There is a drop-in replacement in the form of Monty's MariaDB [wikipedia.org]. Could work.

I don't