Flat file or relational?
 

I just got some contract work progamming a little app for an HR department. As a third-year CS major I'm good, but not great. They want a program that will allow them to (a) create student profiles with name/address/phone/class schedule, (b) track who's working in what room, (c) be able to schedule vacation time for students and still have the rooms automatically assign new sudents, (d) print out schedules for the students and for the rooms, (e) and ideally assign the empty rooms to people with preferences for certain ones.

OK -- background aside; would I get much performance/ease of programming out of using a relational database? Every "assignment" program I've ever written was relatively simple and used a flat-file, so I've got no experience with relational databases beyond CREATE and DROP. Their budget wouldnt afford something like MS SQL, so I'd have to learn AND use mySQL in the two-ish weeks they've given me. There's about 10 rooms and an active payroll around 30-40 students...

So -- would you use a flat file database or a relational databse in my situation?

Just a question, if all you know is create and drop (and I'll guess simple select stuff), what good would MSSQL do?

As for me I'd use a the relational because I think you'll start having problems once you get in the corner cases and the exceptions to rules (there are ALWAYS some).

Good luck though.

The question was moreso whether learning what I need to of a relational database is worth it in the limited time frame of this project (2 weeks) or whether it seems simple enough to work with a flatfile.

Another third year CS student here. I'm completly new to databases (never even took a class). I started learning MySql over the weekend, and it doesn't seem to be too challenging. So I'd say go for it.

On the other hand, given that you are working with such a small dataset, you could probably get away without using such a database...but it probably wouldn't be as nice a solution.

Wish I could be more helpful...

Even if you use flat-file storage, it's relational data. You'll need multiple flat files with relationships between them anyway. Were I you, I'd use the tool that's meant for that.

Besides, it's just as tricky managing file interactions, locks, atomiticity, etc. May as well let the database engine handle all that for you. You'll be glad you have the tools later.

yes, a database, because of the whole mess with opening/writing/locking files.

But the real trouble for someone new to databases is creating a good enough database schema. Make sure it is normalized (http://en.wikipedia.org/wiki/Database_normalization), meaning that you do not have redundant data lying around.

Maybe a.... "low end" database would be the best solution? Something like Access or a free equivalent (don't know of any myself). While not being a great database overall, it will at least help you to get things set up and running, and would be less of a hassle than learning/setting up/using something like MySql.

If you're going to be using MySQL, I would recommend installing apache and php, then installing something called phpMyadmin. Web-based util to do anything with MySQL.

Thank god you're not MSSQL. MSSQL is built to handle massive amounts of data. This isn't an option, whether you have the budget or not. At my work, our Database server is running MSSQL 2000 Enterprise, has 18 databases on it ranging from 6 to 20 gigs in size. I think this would be a bit of overkill for less than 50 people.

You might try looking at Sourceforge.net to see if someone has anything similar to this. It would be free to use, and might give you some direction to go.

Also, if you use apache, mysql, phpmyadmin option, the easiest distros to use it with I believe are debian and gentoo. Their package management systems allow you just to tell is to install and the distros set it all up for you.

Thanks guys. I think I'll check out Sourceforge or see if she has Access. The lady I'm developing this for barely knows how to turn on a computer, nonetheless install a DBMS (or Linux). :( Wish me luck! :)

Just downloaded phpMyAdmin. It's great! I will definately be using this until I know my way around mySql, so that I am more confident with the command line interface. Thanks for the recommendation!

MySQL also has a graphical interface now.
I forget if it's called Admin anymore, but check that out too.

Another CS student here, yeah I agree with some of the possible solutions here. MySQL is the way to go to easy manage the data if your employer doesn't have Access. In this case, it seems that only a max of 10 rooms, 40 possible students (Max?) makes Access the best database solution for this situation. MySQL is designed to be a larger database.

MS SQL is overkill.

You can get MSSQL for free.
Will also PM you to make sure you get it.

MS Visual studio Express editions.
http://lab.msdn.microsoft.com/express/default.aspx

http://lab.msdn.microsoft.com/express/sql/default.aspx

It doesn't sound like you need them for this, but Express doesn't have any of the advanced MSSQL tools.

I missed what language you're writing this in, but if it supports serializing native objects or otherwise dumping native objects to flatfiles, that would be the way to go. If you use CSV flatfiles, not only do you have the same data design problems that you'd have with SQL (normalization, etc.), the programming overhead for reading/writing/updating/deleting lines will be worse than simply learning to use a database server.

Watch what you get yourself into. This may blow up into something that could get you a grant or full-time work if people high up see the value of it.

Make sure you find some software that will scale well and program to that end. You never know, if you retain the rights, you could even sell it to other companies and make a small fortune out of it. =)

You might also consider using SQLite. Free and GPL like MySQL, but it uses regular files for data storage so you don't need to set up a server or mess around with permissions like you do with MySQL. Also, using any language with decent abstraction you should be able to switch between the two fairly easly.

That's what I was hoping for. Alas, the guy flaked out the instant I asked him to give me a detailed specification document of what the program needed to be able to do. Something about his boss being sick, and then it became that he was busy.. etc. I'm done with the project, but thank you guys for your tips. I'll definitely remember these later if I come across a similar database project.

JK, for jobs I've been involved with, helping the spec process is part of my work. If nothing else as self-defense. The jobs of any complexity completed from "spec" either started as school assignments or ended in the trash.

If he knew how to properly and realistically spec the project...?

A note on MS Access: Yeah, the JET engine craps out at 65k records, etc. etc., but the shiny things (forms and other front-end bits) are a snap to throw together, and the standardization of the user interface coupled with it being wrapped up in MS Office makes it an excellent choice.

I use access to build front-ends for big backend databases in mySQL. Anytime the boss wants a new sparkly toy, it's nothing to whip up a new form or report in access built on a mySQL query.

It's almost the best of both worlds, easy Lego frontend, powerful backend. Just that messy connection stuff in the middle.

there was a big discussin on flatfile vs relational DB's on slashdot 2 weeks ago
see if u can dig that thread up

To continue the discussion, my final CIS course at college is based around the two classes constructing a fully operational IS system for a local camp. The two classes are split into four groups. My team is the database group. Right now we're talking very specifically about relational and flatfile databases. Ours is definitely gonna be relational. Our group has developed level 1 and level 2 entity relationship diagrams. This week we're actually taking the level 2 ERDs and transforming them into Access tables using SQL.

Anyone have tips on doing this? We have to make approximately 50 tables in this database, all with at least 4 attributes. Is there an easier way to do this other than going into Access and manually creating 50 fucking tables? I have 3 days to get these done. :) All tables must be related to each other with three levels of normalization. Thanks for any comments or suggestions.

-Lasereth