Large Project opinion

Fellow Monks, I need an opinion rather than asking for help.

First a little outline: I run a Florida (soon to be national) DJ event promotion and music promotion at Full-Fx.Com

I had a functioning events system but it quickly outgrew itself. I am now faced with the following problem...

I plan on making a large community on my website where people can comment on past events, post new events, post pictures of events they have posted or events that already exist. There are a few other things I plan on adding in as well later on which I have not yet decided on. This is the largest perl oriented project I have ever been faced with as it invloves a whole website integration. What would be the best course of action to pursue this in everyones own opinion? I thought it might be better to make "admin" ability only at first and integrate a flat-file user database system later on with multiple different perl scripts working in unison for each different task and page so to speak.

I'm still very vague at the moment of everything I want to include on it, All i know is it will be large and hopefully I want to make it as scalable as possible ( which shouldnt be hard with a flat file db system ) I was going to use mysql but I do not yet have enough knowledge of it at the current moment. Thank you ahead of time.

DKode

"A computer is almost human - except that it doesn't blame it's mistakes on another computer."

Comment on Large Project opinion

Replies are listed 'Best First'.
Re: Large Project opinion by lemming (Priest) on Jun 07, 2001 at 06:08 UTC
Well, you may be able to use http://everydevel.com and vroom who knows it well does have his resume' out. He's ripe for a good telecomuting job. After all a lot of what you're requesting has been done here	[reply]
Re: Large Project opinion by tachyon (Chancellor) on Jun 07, 2001 at 16:49 UTC
I'm still very vague at the moment of everything I want to include on it, Stage 1 of any project is to plan what you want. Often decisions you make at the begining can deeply commit you to a particular course of action. Define what is core (must have) and what is to be placed on the wish list. This way you can get a working system up and then add the frills as time, money and experience dictate. All i know is it will be large and hopefully I want to make it as scalable as possible ( which shouldnt be hard with a flat file db system ) Sorry, this is just plain wrong. Flat files are the worst possible choice for a project that aims to be large and scaleable. Databases basically sprang into existence to fix the deficiencies of flat files in large, scaleable, robust data applications. I was going to use mysql but I do not yet have enough knowledge of it at the current moment. For what you want "Don't leave home without it!" I agree the everything engine +/- Tim Vroom (click here for vroom) may be a good option. tachyon	[reply]
Re: Large Project opinion by Mission (Hermit) on Jun 07, 2001 at 17:05 UTC
DKode, you will probably want to do a lot of reading on this site. There are a few thousand things that you'll need to pull that off. First off, you need to decide what is important, and what is fluff. Then from the important things, what is 'vital' for the functionality, and what is 'nice' to have for functionalilty. I suggest visiting theSuper Search node and start to dig and read. I know that it's great to want everything, but you actually want this to be done in multiple stages (if done in house.) So you will have to identify exactly what needs to be delivered with the first version. If the budget allows, vroom is your best option. (I'm not sucking up, I'm just stating the obvious... look around at PM just look at the creation.) My last piece of advice is to do baby steps into this larger project. It seems to me that you've not used SQL, so I can assume that DBI is foreign to you as well. I'd start with implementing a small CGI DBI that stores, retrieves, updates, and removes data. This would be a good project that will help you determine just how much work this is going to be for you. Finally, keep communicating and participating here at Perl Monks. You'd be suprised just how much you learn just by reading other people's questions and comments. Good Luck! *- Mission* "Heck I don't know how to do it either, but do you think that's going to stop me?!!"	[reply]
Re: Large Project opinion by one4k4 (Hermit) on Jun 07, 2001 at 17:06 UTC
Personally, I agree that flat file db systems are definitally not scalable. To the extent you seem to be considering. I wonder how PM would run with flat files. :) Regardless, I suggest you write. Write a lot. Spec everything out, and read over it. Create a data model in excel, with table layouts, (or flat file(shudder) column layouts), and program flow charts. Even writing a simple paragraph in plain english helps me clear my head and move foward a bit. Sometimes you realize what you can do easier, and what you simple cannot do, by writing and specing (if only to be viewed by yourself) things out before coding. I hope this helps. I spend many-an-hour in meetings here at work, and most of the time I come out knowing what priorities I have to restructure, and usually end up productive that day.. _14k4 - webmaster@poorheart.com (www.poorheart.com)	[reply]
Re: Large Project opinion by Vizjerai (Acolyte) on Jun 08, 2001 at 02:05 UTC
I would have to agree that one of the most important things is to define exactly what is needed and what can be added later. I hate to be working on a project and then a day later realizing that you did the whole thing wrong and need to add something that you didn't think about before, and re-writing everything over again. In my opinion using a flat-file database wouldn't be the best thing to have because it would be harder to add newer things later down the line when you might want to add more features to the message board. For admin purposes I would try and implement it so that there would be multiple levels of users or admins incase the job of moderating it yourself takes too much time. Vizjerai	[reply]


Your skill will accomplish what the force of many cannot
	PerlMonks