Lost in the sea of information

[nanook]

Hi All,

 

I wanted to introduce myself as a new member of this forum.

 

I'm a pc tech working for a consulting company with hopes to go into business for myself within the next year or so.

My expertise is in pc and networking hardware and making them play nice together.

I'm not a programmer of any kind. I do know a little VB and VBscript. I've also done some basic work with MS Access.

 

My knowledge of relational databases is basic. I believe i have a reasonable understanding of the concepts but that's as far as it goes.

I'm trying to design a database to track my customer, invoices, schedule and probably several things I haven't thought of yet.

I find myself lost in the sea of information available on the subject and don't know where or how to start.

 

Googling led me here and I'm hoping this will be my compass to find my way to my destination.

At this point, I'm not at all concerned with the syntax of PHP or MySQL. A command reference will supply that.

 

I don't really know where to start. The only questions I have right now is; How do I design an efficient expandable database?

How do I break down this project into small, manageable chunks?

 

Any advice will be appreciated.

 

[dbo]

Well databases are a very powerful thing for storing and managing your data. In addition though, you want to eliminate any redundant data. You want a customer address for example to exist as a single record so that if you need to update it, it gets updated in a single location. Redundancy in data is one of the biggest things I see with people new to databases.

 

That being said I would say the first step is to come up with a list of all the information you want to store on your customers. It doesn't have to be in any particular order. Try to use some forethought as to things you may not necessarily need now, but perhaps in the future.

 

With this big list of information start trying to logically group it into "buckets" of similar information. Customer information vs Orders, etc.

 

I would then try to create an entity relationship diagram (ERD). There are some handy tools for this type of thing, but even doing it by hand is fine. This is the point that you will start giving things names, datatypes, etc. It will allow you to see how all of the data is related.

 

I'd then spend some time reviewing everything you have done to make sure it will support your needs. It's also a good time to make sure you have an efficient design, etc.

 

The next step would obviously be to implement your design.

 

I hope this was sort of what you were looking for and helps. Let us know if you have anymore questions.

[nanook]

Thanks for the reply dbo.

 

In the few short paragraphs you typed, you  summed up about 150 pages of reading in a MySQL book that I bought.

I wish I asked sooner. I could have saved the 50 bucks and the time to read it. That's the problem I have with reading books on the subject. There's far too much fluff and too little useful technique in them.

I've started reading some of the design articles in the resources tread but their pretty much the same, more fluff than useful info.

 

I have a idea of what I want to store but really don't have any idea on how to create the ERD.

 

I have a picture in my mind on how I want it work but don't know how to lay out the tables and relations.

 

Where can I find some concise info on how to effectively design a database?

 

[dbo]

Well I wish I could offer up some resources on the topic but I don't really have any in mind. Mostly just have it in my head from having done it for years.

 

Just create a list of all the stuff you want to store. Below that, create a list of "questions" that you want to be able to answer for the data. Try to think of things that you might not necessarily need to know right now, but things you may want to know in the future. For example, which customer has been my most profitable over the last 5 years? Then you look at the data you are planning to store. Do you have enough data to answer that question? It's really sort of a way to check your work.

 

Do this first step, document it well, and post your findings. We can then help you move forward from there.

 

My other question is... are you set on custom building your own system? There is very likely a host of low cost (even free) packages that would do exactly what you want. If I were starting a new business like you're talking about I would want inventory tracking, ordering/billing/invoicing, perhaps customer relationship management (CRM), and probably a support system. Does that sound about right? Can you think of any other needs we might be forgetting?

[dbo]

Just sort of an aside note on the topic. All of this stuff will be easier to implement up front rather than trying to add new technology to your business while trying to run a business. I wouldn't let the technology aspect halt your decision to move forward with your plans, just saying try to head off as much of your needs as possible.

 

The way I typically do new product/business development is start with an exhaustive list of things you think are valuable... a wishlist if you will. From there sort of prioritize the list and then phase them in. Lots of times you can find out that 20% of the features you've listed will encompass say 80% of the total value. These few items that make up the 20% are probably where you should focus your initial efforts.