A Database for the Office?
travellerjohn asks: "I work in a small company (200 people in 7 offices), where the staff uses Microsoft Access to create various databases. Most of the time they lose interest before the databases become complex or important enough to warrant the IT department getting involved. However, from time to time, someone turns up at our door looking for help with their pet project, often starting with statements like 'it should work over the intranet' or questions like 'why can't it store documents and pictures?' or 'how do I control user access?' When we sit them down and explain how much it will cost to rewrite their database in PHP/VB/JSP, or whatever we sound unhelpful and expensive. What database tool does Slashdot recommend I provide our staff? It has got to be easy to use, web enabled, capable of storing documents and pictures and offer user level security. We have tried Sharepoint with some success but that is pretty limited, too, and I have looked at Oracle Application Express. Open source would be good, but I would pay for the right product. Any suggestions?"
It seems like the work flow (what's the right term here) is out of whack there. Database projects that "lose interest before they become complex or important enough to warrant the IT department getting involved"? It reminds me of the commercial where they discover they don't have any computer problems so they can refocus on the real purpose of the company.
In a 200 person company, I would get rid of Access on the desktop. I see the appeal, but it's time for the IT department to step up and consolidate database development/maintenance so that it is more centralized.
Once IT takes control of all databases, all sorts of things fall into place, such as security, backups, moving to a single technology (SQL Server or MySQL), etc. At first it is a bit more costly and people will complain about losing flexibility. But in the lgng run, it is cheaper and people who do OTHER work will find it nicer to be able to focus on their core expertise.
"If you want to improve, be content to be thought foolish and stupid." - Epictetus
You could always set up a MySQL server with PHPMyAdmin and have them learn SQL.... :-P).
On a more serious note, you might just consider rolling your own application. Set up a MySQL (or Oracle, or MS SQL, whatever you like) database, then roll your own application that will meet the needs of the various departments. Keep tally of the features that people are asking for on their specific projects, and include the most common ones. Once everything is finished, then just allow departments to port the database over themselves (you could write an app to import access databases if you want- though users should be punished at least a little bit for using Access
Famous Last Words: "hmm...wikipedia says it's edible"
I've been kicking around building an OSS database utility to compete with the likes of Access and Toad. It would be based on PHP, SqLite, and ODBC. However, I cannot find a decent open-source JavaScript editable data-grid control. They tend to have one big flaw or another. Maybe in another year such will finally mature. Data-grids are a must for such a util.
Table-ized A.I.
Holy crap. Moving them from Access to Excel is a good thing? Are you nuts? If you don't like rogue Access apps, the solution is to offer a better solution, not ban the technology that comes closest to solving their problems.
Assuming there aren't internal resources, get some broad guidelines for those rogue people and better yet, cultivate a stable of smart outsiders who can be the "approved" rogue IT for when business people bypass IT and do their own thing using Access. If you are going to have rogues, have good rogues.
Pick whatever database backend you like; big, centrally managed, scalable, as complex as you like. IT manages it; handles the schema and maintenance, necessary stored procedures. A professional data architect in the IT department has final say on the architecture, but works with the requesting parties to ensure that it can fill their data needs. If necessary, views or similar can be constructed and made available on top of the actual data structure to make it easier for the non-programmers to interact with. You then expose, with appropriately restricted permissions, the database server to all these people with their small pet database projects. You know that most of them are going to be looking at most of the same basic table structure--they need names, phone numbers, whatever. It's a decent bet, since they're in the same company, that they're actually going to be storing the same data, no less. Let them at it--give 'em ODBC connections and turn 'em loose.
They do the work; you give some input and assistance, but don't turn any of them into full-blown development projects. All you have to do is manage the backend. They get to scratch their itch, you get to look helpful and enabling, and no one gets sucked into big, expensive tools or projects.
No relation to Happy Monkey
Sounds like you need a content management system, not just a database. Your users basically seem to wish for a way to share project-related materials. I see you've already considered that...
...so I'd definitely be interested to hear what limitations you ran into there. It's highly possible that some of the open CMS systems (Drupal, etc) could offer you what Sharepoint doesn't, but it's hard to say without knowing exactly what parts of Sharepoint you found limiting for your needs.
You might also consider a hosted collaboration tool such as Basecamp. I haven't used it myself but it has quite a few fans. It's probably more limited (and certainly less extensible) than software like Drupal but the ease of administration (since it's hosted) and easy accessibility (since it's not on your LAN, it's on the 'net) could compensate. Then again, if you're the IT guy... perhaps you don't want a zero-administation solution for job security's sake. :)
OtakuBooty.com: Smart, funny, sexy nerds.
Programmers very seldom consider the needs of analysts, and honestly they tend to slow them down. If all companies were to "BAN Access", many businesses would grind to a halt. But hey, if it gets another PHP script jockey a job, it's all worthwhile I guess.
Ive used postgres ODBC with Access ( just expremental, we have real MicroSoft SQL licenses ) and it seemed to do fine.
Using the native jet database is bad anyway, as you mentioned.
---- Booth was a patriot ----