The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
Database thingy
ben0207
Registered User regular
Registered User regular
Righto, my girlfriend has asked me to help her with a work project. It's for a company database, pretty simple stuff. Up to 1000ish entries (with leeway for more), being accessed over a local network only for up to 50 clients. The entries them selves are just name, address etc with no relationships or anything as far as I know.
The problems with which I require help and advice:
It will be based in Germany. I'm based in England.
Likewise, I only speak English, not German.
It will be used and maintained by non-techncial people exclusively. Hence it needs to be simple
They don't want any vendor lock in at all
It needs to be properly secure, if possible not in any way accessible from the internet.
They have a pretty non-existant budget.
Now my first immediate thought was "oh shit, what have I agreed to doing", followed immediately by "seriously I am fucked". Then I though about it a bit more, and would a Wiki be appropriate? Easy to maintain and edit for one thing, and they can handle the scale we're talking about.
But basically, I have no fucking clue where to start, and I'll be back to doing the five-finger waltz if I don't come up with something. Help!
The problems with which I require help and advice:
It will be based in Germany. I'm based in England.
Likewise, I only speak English, not German.
It will be used and maintained by non-techncial people exclusively. Hence it needs to be simple
They don't want any vendor lock in at all
It needs to be properly secure, if possible not in any way accessible from the internet.
They have a pretty non-existant budget.
Now my first immediate thought was "oh shit, what have I agreed to doing", followed immediately by "seriously I am fucked". Then I though about it a bit more, and would a Wiki be appropriate? Easy to maintain and edit for one thing, and they can handle the scale we're talking about.
But basically, I have no fucking clue where to start, and I'll be back to doing the five-finger waltz if I don't come up with something. Help!
ben0207 on
0
Posts
With Open Office, you can use a wizard to create the tables if you know nothing about SQL, then the employees can insert, update and search through the table with an interface that is similar to MS Excel.
As for security, you'd have to go pretty far out of your way to make it accessible over the internet, so no problems there.
The most point-and-clickable alternatives would be something like FileMaker Pro, which insulates you completely from the SQL/tables side of things, or perhaps ACT! contact management software. Both of these break your "no budget" rule as they're commerical products and each user would need a license.
But yeah, initial configuration of MySQL can be confusing for people new to databases, but it's just a one time hump and after that, you shouldn't need to bother with it again (not to mention if you wanted to do your wiki idea, you'd need to setup a sql database anyways, along with a web server and the wiki software.)
If you don't want to deal with any technical hassles, what DrFrylock suggested would definately be an ideal solution.
edit: another easier way to get a SQL server running is Microsoft SQL Server Express. You can use the management studio it comes with to really make things easy, and it's free, but it violates the vendor lock-in rule...
And there are wiki engines that support proper SQL queries, so they still have all the advantages of using a "proper" database.
You could use a wiki that uses a plain-text file as storage. This minimizes installation hassle, is easily backed up and in case you decide to pack-up the wiki server, it's easy to just open the file and read it. Downsides are that it's less secure and performance would be reduced with many people accessing the file at one time, but that may not be an issue here and if the file is kept on the internal network, security also may not be an issue.
Take a look at Dokuwiki ( http://wiki.splitbrain.org/wiki:dokuwiki ), which 'only' requires you to get a web server that can serve PHP pages (like Apache) running.
I'll play with this Dokuwiki thing on my iBook (it has Apache builtin and already configured) and tweak it to meet their requirements.
Tell me if I am wrong:
- You have a team of non-technical people who you can't communicate with as they all speak German.
- These people don't know anything about databases, and cannot be expected to be trained to understand them.
- You don't know anything about databases either.
- Said German people need a way of storing and accessing information of about 1000 or so identical records.
- You want a web interface to the records.
- It needs to be free.
A wiki is not a good way to do this at all. I know snarks is just trying to bend to your requirements, and he offered up a fair solution (TWiki is another plain text storing wiki) but it really is not the way to go on this. He was right the first time; you need a database of either the MySQL or PostgreSQL flavour. You're trying to store identical data and the requirements for that data will change. If you go down the wiki road, you might well fuck yourself later as you have no way of assuring data integrity or formatting, and when you have to accommodate the new requirements, you will find out you can't. And these requirements could be very obvious, like trying to find out how many clients live in Munich. You can do this really easily in a database. You can't do it in a wiki.
I also suggest you model your data so that it changes over time: one person can live in several different addresses over the course of the years, you should reflect that in case historical data becomes important. You would then need a one-to-many relationship between a person and their address. However, this makes things more complex.
If you want the absolute bare-bones, do it in MySQL with a German translated phpMyAdmin as the front-end for the employees. However, snarks suggestion of building the front end in OpenOffice is a good one.
Don't do it in a wiki, it's not suitable at all.
Thanks for the honesty. I'll look into phpMyAdmin. The Wiki thing was getting nowhere, and I've been playing with it soldily for a few hours.
I'm still not a million percent sure how they expect me to install or maintain this thing from here when it is located in Germany, but I figure I can walk the GF through it before she goes back next and her employers can get a temp in when it breaks.
Installing and maintaining is the easy bit, you just need shell access to a server somewhere (you don't even need root access, but it'll help). Very few DBAs have the luxury of being able to physically access the box they are working on, and 99.9% of the time, you don't need that access. The difficult bit is distributing the front-end and training the users. One will have to hope that the company has thought of this.
I guess her employers are trying to keep this project cheap by keeping it in-house, but if nobody involved with this project really knows anything about any of this stuff, it might just be worth it to get someone well versed in this stuff locally from the start. Depending on how often this data will be referenced/updated and how sensitive this data is, it could be worth it just to suck it up and get a local developer to setup a server and develop a custom php web interface for you.
Which is really the crux of the problem here: general tools are too general. There has to be someone hired to properly customise any software solution.
Sharepoint is pretty neat for mini-projects like that.