homepage Welcome to WebmasterWorld Guest from 54.198.130.203
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Subscribe to WebmasterWorld
Home / Forums Index / Code, Content, and Presentation / Databases
Forum Library, Charter, Moderators: physics

Databases Forum

This 33 message thread spans 2 pages: 33 ( [1] 2 > >     
I believe I need a database, but how do I start the process?
Are there standard questions that a competent db programmer will ask me?
Webwork




msg:1579163
 3:43 pm on Sep 16, 2005 (gmt 0)

Since this is a request for "generic guidance" the subject matter for the database could be real estate, jobs listings, equipment for sale, event info, directory listing, etc. Assume that I can craft the HTML, CSS, graphics, site nav, etc. and that I'm "only" asking for guidance about the "interactive programming" issues, if that makes sense. ;) (If not, say so.)

I assume I need provide the following information to a database programmer:

  • List of the data I wish to retrieve/store (name: first, last, middle initial; street address, etc.)
  • List of "types of searches" I wish to enable (search by price, State, etc.)
  • Security processes (password protection)
  • Data expiration and storage upon expiration (archive?) requirements
  • Payment processing info (if paid listings)

Beyond the above list I really don't know what basic or essential information I should have available to make the database programmer's job easier.

Is there information, common to the creation of most databases, that a database programmer needs to start the process? What is common?

For website development purposes are most/many database programmers able to not only craft the backend database but also the user interface? SQL + ASP.Net? PHP + SQL?

What information should I assemble before seeking the assistance of someone to develop a database driven website? Field names, queries, what?

Are there "frequently overlooked issues", that non-dbprogrammers fail to consider, when they first seek to "set up a database driven site"? (My non-expert way of describing what I have in mind.)

Forgive the multiple questions or several versions of the same. I really know little about what I'm asking for when it comes to asking a programmer to develop a database for me. ;(

So, I ask: How do I make myself a resource, not a hindrance, to the db developer?

Have all my questions already been answered or all the issues already addressed here: [webmasterworld.com...]

 

chronic




msg:1579164
 5:06 pm on Sep 16, 2005 (gmt 0)

There are many views on database engineering, and I've seen a lot of different attitudes/approaches. Most of it comes down to what degree you normalize - break up the tables into sub sets. For instance you have a user driven site, do you have:

userTable: username (char), password (char), typeofuser (char)

or do you have

userTable: username (char), password (char), typeofuser_foreignkey (int)
userTypeTable: typeofuserid (int), type (char)

The answer is not simple, and it is up to you to decide how much you want to direct or misdirect your engineer.

One is more re-usable and flexible, the other is quicker to develop and faster (execution-wise), and the answer lies in what type of site you are building, what your budget is, and how long you are willing to wait.

As far as technology, my rule is to decide what I'll be able to maintain or reuse when the programmer dissapears. Do you have a freind who knows php but not asp? Can you hire mysql developers easier than SQL Server? Etc.

Webwork




msg:1579165
 8:34 pm on Sep 16, 2005 (gmt 0)

Thanks Chronic.

What questions should I expect a database programmer to ask me?

Is there a standard "this is what we need to know to get started" list of questions?

volatilegx




msg:1579166
 8:51 pm on Sep 16, 2005 (gmt 0)

Chronic brings up a good point, but I think an experienced database programmer will be able to handle these decisions for you. Most non-experts won't know to ask questions about normalization, and most could care less.

Being a guy who occasionally does contract work for MySQL databases (database driven websites), I have worked closely with clients who have not a clue about how databases work; they only know they need one.

* List of the data I wish to retrieve/store (name: first, last, middle initial; street address, etc.)
* List of "types of searches" I wish to enable (search by price, State, etc.)
* Security processes (password protection)
* Data expiration and storage upon expiration (archive?) requirements
* Payment processing info (if paid listings)

The above is a good starting point to work with a programmer. Adding to that would be to mention a budget you would like to stay within and a time frame for completion. Above all, be prepared to be available to answer questions asked by them.

Some of the things I would demand of a database programmer:

* a useable interface for you to be able to enter new data, edit existing data, etc., which would also have
* a reporting feature which would allow you to export data
* an importing feature that would allow you to easily import large amounts of data
* an automatic method of database backup, preferably by cron job. You would probably be responsible for downloading/archiving the backups, though.
* a maintenance plan, so the programmer could go back in the future to correct any errors, etc.

It would be a good idea, as a site owner, for somebody considering having a database-driven site, for them to pick up a reference on the database of their choice, so they will be able to understand the lingo of the programmer.

iamlost




msg:1579167
 10:12 pm on Sep 16, 2005 (gmt 0)

So you think you need a database. :-) Have I got a deal for you!

Your question was very broad - so my answer is too. Most clients and far too many DB "experts" start at the end of the process. Yes, your data specifics (name: first, last, middle initial; street address, etc.), query types, etc. are the climax not the beginning of the story.

Not every question below is required for every DB (and many more are needed for some) but they give an idea of the process that eventually leads to your data specifics, normalisation, et al.

1. Client:
What do you expect a Database to do now?
What do you want it to do five years from now?
When do you want it operational?
What budget have you set for design, for implementation/testing, for operation/maintenance?

2. Current Information:
How much information do you have i.e. 84-file cabinets, 482-GB on disc?
Where is it located?
What media is information currently on i.e. paper, tape, disc, etc.
How is information currently categorised i.e. Personnel, Finance, Inventory, Sales, etc.?
What laws/regulations (i.e. Privacy, Medical, National Security, etc) apply to what information groups?
How is information currently managed i.e. who does what, when, why?

3. Current IT:
Is this all from new?
If not, what is existing hardware and software i.e. OS and what constraints does existing stuff impose i.e. Win/*nix?

4. Proposed System:
One large or multiple smaller (distributed) DBs?
Required DB performance?
Available/proposed storage: DAS/NAS/SAN?
Load distribution design/management?
In future is plan to scale up (on same server) or scale out (across multiple serrvers) or a combination?
Where is failover required/appreciated/not needed?
How to manage data (central/distributed)?
What level(s) of security (see laws/regs above also)?
Where is encryption required/appreciated/not needed?
What metaData and metaData access, limitations, and logging?
What level(s) data backup/recovery?
What level(s) data deletion?
What are various data mining requirements?
How many distinct GUI are required? Stock or custom?
How is current data to be entered/confirmed? Can any be directly imported? Is a redundent enter system required?
How is future data to be entered/confirmed?
Which Database system best matches current and future requirements, hardware, and OS?

Eventually the "system" is determined.

Now the stuff that most people think of as "Database Design" can be addressed - normalisation, table layout, etc. Actually they are but the icing on the cake. Everyone likes to stick their finger in the icing. The real cooks know how to bake the desired cake and then apply the icing.

aspdaddy




msg:1579168
 3:52 pm on Sep 17, 2005 (gmt 0)

One way I have worked in the past.

The client gives me all the html pages of the site including what a search results page looks like, a single record page, before and after Paypal or WorldPay pages, and the step by step pages to create an account or make a listing. Everything ready for database integration.

Usually I will tell them theres stuff missing like bad credit card page and error pages.

They also let me know where the site will be hosted and I call the host if I dont know them already to check what db they support - Access, MySql or MS SQL.

The only questions I need to ask is about requirements for security, volume of data, backup, response times and administrative functions and of course budget and timescales.

All the normalisationa and designs I will decide based on the above.

What are various data mining requirements?

I would not ask stff like this at this point, client are usually focussing on getting a prototype working site to show sponsors etc.

Questions like this increase the initial cost and are better handled with subsequent work, IMO.

iamlost




msg:1579169
 12:45 am on Sep 18, 2005 (gmt 0)

Basic Truths Clients Rarely Know And Never Like:
Truth 1: DB design is expensive. Typically works out to 3-5 times the hourly rate charged by "web design" firms.
Truth 2: At least 80% of DB design/build is intangible. The deployment of the DB and its data population near project end is the first true substance client "sees".

This means that the client may only learn what works (or not) after a lot of time and money has been spent. It is why reputation is a DB designer's most cherished asset.

Note: A good DB designer/programmer gets paid to discuss the project/determine requirements whether s/he actually does the job. The DB/GUI build, etc. is a separate issue/contract. Did I mention DBs are expensive?

For website development purposes are most/many database programmers able to not only craft the backend database but also the user interface? SQL + ASP.Net? PHP + SQL?

Solo operations (plus subs if required) like me do it all. We may lean more to one of Win/asp or LAMP (me LAMP) but tend to be generalists. Larger shops tend to have more people in narrower specialities.

Using your scenario (new site from scratch) and your stated capabilities:
* Would expect you to provide the templates (html, css) and the content (text, media).
* Could you also handle client-side scripting (ie javascript) if required?

Level 1:
* timeframe expected (you will always be too tight).
* budget allowed (you will always be too tight).
* detailed sitemap (if you don't have one you aren't ready for a DB).
* is user content expected (reviews, fora).
* rate you expect to add pages (content, product, other).

Level 2:
* forms (number, info, actions)
* shopping cart (stock, customised-stock, custom)
* cookies
* registration

Level 3:
* webhost platform (Win/asp, LAMP, etc.), access, security, support, etc.
* site/visitor analysis
* site security and logging

I agree with volatilegx that an admin GUI should be standard. It can be as simple or complex as the actions you want to accomplish - think about them and discuss with your DB designer. Also a "troubleshooting" period after going operational. An ongoing maintenance contract is a good idea but optional to getting a working DB.

The above would give sufficient information to allow a DB designer to decline the project or present a proposed contract and price (likely with options). If based on only some or all of the above would include costs to flesh out requirements.

Webwork




msg:1579170
 4:00 pm on Sep 18, 2005 (gmt 0)

I knew there was a reason why I've been "stuck" (not making progress) on database development. There's a lot to the process, isn't there?

I've spent the last few hours going over your posts, attempting to work your guidance into a checklist that I can use for planning my actions leading up to hiring a programmer and working with a programmer.

Below here is my checklist, summarized from your very helpful and kindly shared comments. If there's any "categories" (capital letters) or "issues" that needed to be added under any category please point them out.

What I'm working towards is a general "thought provoking checklist or tickler" that I can use when evaluating my loosely fashioned database driven website plans or ideas. I plan to used this checklist to help transform my ideas into a concrete action plan. In the process of working through the checklist I'm hopeful that I'll becomea better client. ;0) (Your efforts and the checklist might even make others - who find this thread - become better clients. Heck, if I get this right, you might even give a copy of this thread to a prospective client. ;)

So, here's my checklist as it now stands, subject to further revision:

* * * * * * * *

PRELIMINARY: Buy a reference book on database design to learn the lingo and basic concepts

EXISTING DATA & INFO TECH:

How much data do I currently have?
Where is it located?
Storage media: paper, tape, disc, etc.
How is information currently categorized?
If not, what is existing hardware and software i.e. OS and what constraints does existing stuff impose i.e. Win/*nix?

* * * * * * *

CLIENT/PROGRAMMER BUSINESS RELATIONSHIP ISSUES

BUDGETARY ISSUES:

Budget limit & breakdown: design, implementation, testing, maintenance
A good DB designer/programmer gets paid to discuss the project/determine requirements, whether s/he actually does the job.

TIMELINE ISSUES:

Deadlines? Commitments?
Programmer/client response or reply times?
Client deadlines for providing information to start process? For steps in process?
Third-party integration issues? (Payment processor providing info, code, etc.?)

WHAT CLIENT WILL OR CAN PROVIDES:

TEMPLATES & CONTENT, FORMS WITH FIELDS:
Pages needed to create: an account, a password
(Data carried forward page-by-page? Rollback page? Error handling by javascript? Process failue page?)
Pages needed to create a listing, step by step
Search page
Search results page
Page design for presenting a single record & multi-records
Payment entry pages
Payment approved pages
Bad credit page
Error pages
Client-side scripting/java script(?)
Site map
NOTE: Need for technical/procedural text to match programming

HOST INFORMATION:

Confirm host db support
Types of db supported
Storage
Web host platform (Win/asp, LAMP, etc.), access, security, support, etc.
Site/visitor analysis

MISCELLANEOUS:

Cookies use? Data stored? Use?
EMail confirmation?

* * * * * * *

DATA ISSUES:

Data I wish to retrieve and store (company name, address, phone, etc.)
Data searches I wish to enable (search by price, location, etc.)

DATA GROWTH ISSUES:

What level of growth is expected?
Should current design anticipate growth to level x, y or z?

DATA SECURITY ISSUES:

Website security vs. data security?
Event logging and reporting?
Legal requirements imposed on data collection and liability for disclosure?

DATA ADMINISTRATION GUI (should be standard):

What administrative functions will be handled via an online interface?
Reporting furnctions?
Add or change data collected? Add fields?
Reporting feature - to export data
Importing feature - to import data
Automatic database backup (cron job)
Maintenance plan to correct errors

DATA STORAGE ISSUES: Back-up, archive, deletion:

Where/how will data be stored? (Same HDD, SAN, other)
Data expiration?
Data handling upon expiration? (Archive?)
Local data back-up?
Remote data back-up?
Compression?

DATA ANALYTICS AND DATA MINING:

*I don't even know if this IS part of the planning process

DATA OR PROCESS INTEGRATION ISSUES:

Payment required?
Payment processing? (SSL with gateway? Pay Pal? Other?)
Payment information storage?
Shopping cart (stock, customized-stock, custom)
Recurring charges issues: Record, notify, confirm, cancel account

LEGAL CONCERNS:

What laws/regulations apply to what information groups?
How will this effect what data is collected, stored, available for public view?

DATA MANAGER INFO:

Current management: Who does what, when, why? How will this change?
Future data management: Who will have what level of access? Safeguards?
Password protection protocols?

ALTERNATIVE SOLUTIONS AND ISSUES:

One large or multiple smaller (distributed) DBs?
DB performance requirements or options?
Storage: DAS/NAS/SAN?
Load management?
Growth: Same server or multiple servers or a combination?
Fail over?
Central or distributed data management?
Security requirements dictated by law or regulations? (HIPAA)
Encryption?
What metadata and metadata access, limitations, and logging?
Data mining requirements?
How is future (revised, updated) data to be entered/confirmed?
Which Database system best matches current and future requirements, hardware, and OS?

jessejump




msg:1579171
 10:47 pm on Sep 18, 2005 (gmt 0)

Is there a site that runs a database with similar functions to what you want?

surfin2u




msg:1579172
 11:22 pm on Sep 18, 2005 (gmt 0)

Hi Webwork. It seems like just yesterday that I responded to a thread that you created about needing a programmer to perform some work for you. This thread sounds like you need technical help again and my advice to you remains the same.

Don't try to imagine that you can turn yourself into database designer overnight. Find someone, who you can trust, and work with over the long term. I'm talking about a technical person, who will have a interest in the long-term success of your business. Develop a relationship with that person that probably involves part ownership or profit sharing, after you decide that you've found the right person. Your developer should have a deep understanding of your business from the perspectives of the owner, clients, and if appropriate investors too. Let your developer ask the questions about what's needed for your database, or if you even need one.

graywolf




msg:1579173
 1:05 am on Sep 19, 2005 (gmt 0)

It's an oldie, but still a goodie Your First Databse [webmonkey.wired.com] from the webmonkey.

Kirby




msg:1579174
 1:25 am on Sep 19, 2005 (gmt 0)

I love that one, graywolf. I had my last programmer read the part about insertion anomalies just before I fired her.

Webwork, with the sheer number of directories that are on your drawing board, surfin's advice is something to take a long hard look at.

surfin2u




msg:1579175
 1:36 am on Sep 19, 2005 (gmt 0)

I just checked out webmonkey and I was disappointed. The first few paragraphs take jabs at developers for trying to make building a database sound too hard for the average Joe.

It reminds me of a language called COBOL that was invented so that managers could fire all those pesky programmers and write the code themselves. Make a programming language look enough like plain English and anyone will be able to write it.

WRONG!

COBOL had its heyday and now it's pretty much defunct, except on the few remaining mainframe computers out there. Managers aren't writing programs because programming is difficult and should be left to ones, who know what they're doing. Even when COBOL was big managers figured out that they weren't up to the task.

If you want your business to be run on an amateurish foundation that may be full of holes, then go ahead and give building your own database a try. You might say, what the heck, what have I got to lose?

If you're serious about your business and need a professional quality product then pay a professional, who knows what they're doing because they've been trained and have plenty of experience, and have references to back that experience up with.

The subject of this thread was what questions to ask a developer, not how to become one in 24 hours or less.

My answer is figure out how to determine who is a competent db programmer that you can trust, and then let that person ask the questions of you.

podman




msg:1579176
 2:09 am on Sep 19, 2005 (gmt 0)

If it's more than a trivial database you need a seriously competant database designer. Most programmers do not have a clue about proper database design. Most managers think a little desktop Access application is a real database.

Little mySql dohickys for storing data are mostly a bunch of tables, and although they may work for the intended purpose are probably not well thought out databases that can handle real life information and exceptions.

markbaa




msg:1579177
 3:06 am on Sep 19, 2005 (gmt 0)

I agree with podman. Having said that, most websites are probably ok with having a fairly basic database. I'm a programmer with database experience, but as soon as the database hits about 5 tables, I know I'm getting out of my depth and will try and get a database expert in.

The other thing I'll add is make sure you get someone with some business savvy. I've worked with people who are database gurus, but unfortunately, can't see the forest for the trees. They may in fact end up engineering for all sorts of exceptions which in reality are unlikely to ever happen. Do you REALLY want to pay $1000 for a clever technical solution that's only going to happen realistically once a year if that, and could be replaced with an error message and perhaps a prompt to contact support? I've spent a lot of my career managing such people (having enough database knowledge to call out problems), and know that both under engineering and over engineering are both very common.

Webwork




msg:1579178
 3:20 am on Sep 19, 2005 (gmt 0)

Trust me I'm not giving the slightest thought to attempting to learn to do this myself. ;)

My first inquiry was about how to approach programmers in general. Am I to understand that all forms of "programming" are the same or have the very same issues? I get the feeling that's not quite the case, but what do I know?

Did the general programming thread answer all questions relevant to database development?

I know I will need the assistance of people with expertise in "all things database", but heck, I'm not even certain what to call such people: Are database developers simply called "programmers", are they DBAs, or backend developers, or front end developers? Who or what, exactly, am I seeking?

Does one person do it all when it comes to building a database driven website?

I assume that someone with expertise in "all things database" would have a list of questions they would like answered in order to fulfill my vision/business plan/idea. I assume that I will be called upon to answer those questions as I move ahead.

As I examined the initial responses in this thread my eyes started to roll back in my head: Fail over? SAN? Load balancing? Provide guidance for development of an administrative GUI?

I was kinda focused on "name, street address, price". Ack! I can see the need for a reference book. I don't even speak the lingo.

So what is it I - or anyone with an interest in having a database driven website - have to come prepared to discuss, explain, grasp or answer - when it comes to hiring someone to develop a database driven website?

gomer




msg:1579179
 4:31 am on Sep 19, 2005 (gmt 0)

Webwork, I feel for you. The task at hand is large but I think you have the right approach, stay with it. Don't let a lot of unnecessary lingo make things more complex for you than they need to be.

In my opinion, you should not be discussing fail over, SAN or load balancing. If you are discussing those things, you have probably picked the wrong person to assist you. Yes, something like an interface where you can enter data and administer processes is good.

Sometimes people make things more complex than they need to be. Choosing such help is the worst decision you can make.

You have received some very good advice here on these first two pages of this thread. At this stage, knowing who to listen to is difficult but that is the most important decision you are going to make.

Here are some quotes from this thread of advice that I think are bang on in terms of what you need. It is worth repeating.

volatilegx:


* List of the data I wish to retrieve/store (name: first, last, middle initial; street address, etc.)
* List of "types of searches" I wish to enable (search by price, State, etc.)
* Security processes (password protection)
* Data expiration and storage upon expiration (archive?) requirements
* Payment processing info (if paid listings)

The above is a good starting point to work with a programmer. Adding to that would be to mention a budget you would like to stay within and a time frame for completion. Above all, be prepared to be available to answer questions asked by them.

Some of the things I would demand of a database programmer:

* a useable interface for you to be able to enter new data, edit existing data, etc., which would also have
* a reporting feature which would allow you to export data
* an importing feature that would allow you to easily import large amounts of data
* an automatic method of database backup, preferably by cron job. You would probably be responsible for downloading/archiving the backups, though.
* a maintenance plan, so the programmer could go back in the future to correct any errors, etc.

aspdaddy:


One way I have worked in the past.

The client gives me all the html pages of the site including what a search results page looks like, a single record page, before and after Paypal or WorldPay pages, and the step by step pages to create an account or make a listing. Everything ready for database integration.

Usually I will tell them theres stuff missing like bad credit card page and error pages.

They also let me know where the site will be hosted and I call the host if I dont know them already to check what db they support - Access, MySql or MS SQL.

The only questions I need to ask is about requirements for security, volume of data, backup, response times and administrative functions and of course budget and timescales.

All the normalisationa and designs I will decide based on the above.

What are various data mining requirements?

I would not ask stff like this at this point, client are usually focussing on getting a prototype working site to show sponsors etc.

Questions like this increase the initial cost and are better handled with subsequent work, IMO.

surfin2u:

Find someone, who you can trust, and work with over the long term. I'm talking about a technical person, who will have a interest in the long-term success of your business. Develop a relationship with that person that probably involves part ownership or profit sharing, after you decide that you've found the right person.

Choose the right people and they will take care of most of your headaches. Keep things simple.

RossWal




msg:1579180
 6:22 am on Sep 19, 2005 (gmt 0)

COBOL had its heyday and now it's pretty much defunct, except on the few remaining mainframe computers out there.

  • 70 percent of the world's data is processed by COBOL.
  • 9 out of 10 ATM transactions are done using COBOL.
  • 30 billion online COBOL transactions are processed daily.
  • 492 of the Fortune 500 use COBOL.
  • The entire 100 Fortune use COBOL.
  • Current COBOL investment tops $3 trillion.
From here [faculty.ccri.edu]
Disclaimer: Looking at the spelling of that URL doesn't instill great confidence

As to webwork's question, in my experience designing industrial strength databases has always started as a business analysis function with the creation of an Entity Relationship Diagram (ERD). This is a great way to work out the pieces of information you need and the relationships between them.

Usually a data guy will facilitate diagramming sessions with the people who know the business. This is the level at which the team would uncover such things as a customer having a billing address AND a shipping address. Or multiple shipping addressses and one billing address. Or, as we were discussing in the local forum recently, one phone number driving the display of multiple locations (banks using a centralized call center). This is typically a very enlightening process that anyone can understand, and leads to the discovery of design defects and missunderstandings in the early (cheap) phases of the project.

Try googling:
Entity Relationship Models
Data Modeling 101

A database programmer would transform the information catured in the ERD into a physical database design.

Josefu




msg:1579181
 7:34 am on Sep 19, 2005 (gmt 0)

I also am relatively new to database creation/maintenance - I'm on my third. Yet in my short experience I found that there is no better approach to the task of database mapping than good 'ol pen and paper. What information will be needed where? What is the information that will be called "at once" (like names, addresses, etc) from a page, but will other query types also need that information? (This question would avoid redundency and a harder maintenance should you later have to change that information.) The thought process would be like putting post-its into labelled boxes, and your paper should be a series of titled lists. But why not use post-it's?

I've found that the best is the ergonomical approach. It's hard to the un-initiated, but in a way you're going to have to actually imagine your database functioning to get it sorted out right the first time. Also for maximum growth potential (and less work later) you're going to have to imagine what information you may add in the future and leave your design 'open' towards that possiblility.

markd




msg:1579182
 7:59 am on Sep 19, 2005 (gmt 0)

Not to add another 'tier of woe' to this very useful thread, but I think there is another issue here:

It's not so much how does someone who may be of a 'web design/webmaster/client facer' background explain to a database programmer what is required.

Just as important is what questions that person asks the 'end client' about the functionality they require or you would like to suggest to them they have. I find that most clients don't actually know they need a database to achieve the functionality they want. They are more focused on their 'wish list' and will probably rely on us to advise them what is possible and not possible - within the constraints of time, budget and technical possibility.

So I suppose you have to have a list of questions to ask the 'end client'(or connect your own proposals to them to a realistic, technically possible solution), identify that they require some kind of database solution, and then brief a programmer?

A good programmer will help you rationlise the brief - I find the biggest challenge for the non-programmer is being able to apply technical solutions, and offer sound advice based on what is possible, to a clients wish list.

iamlost




msg:1579183
 5:29 pm on Sep 19, 2005 (gmt 0)

None of the response to the initial question is "wrong". There does seem to be an assumption that a DB will be a basic web server and/or e-commerce backend. As the original question was open ended some of the answers addressed larger more complex site and B2B considerations.

It is only after a client has said what they want the DB to do now and in future that questioning can be limited.

It is also amusing that certain functions/terms are considered "inappropriate". Depends on the DB requirements.

The initial question:
Since this is a request for "generic guidance" the subject matter for the database could be real estate, jobs listings, equipment for sale, event info, directory listing, etc.

could be for a small content site, a large affiliate site, an auto gen scraper site, or a national or international B2B site. The questions needing to be asked for each often vary greatly in kind, detail, and importance.

Conversation should always be framed to the client - in this instance with Webwork (and other WebmasterWorld members) I would expect a greater level of technical competence/understanding than a COO with an MBA.

aspdaddy




msg:1579184
 6:11 pm on Sep 19, 2005 (gmt 0)

This is the level at which the team would uncover such things as a customer having a billing address AND a shipping address

If it were for a brand new business system, thats maybe acceptable. For a web backend, If the client needs "data guys" and ERD digrams to figure this out, I'd probably pass on the job :)

gomer




msg:1579185
 6:43 pm on Sep 19, 2005 (gmt 0)

Sorry but I had to reply to that info about Cobol. That info is more fiction than fact in my opinion.

First, the size of US GDP is about 11.7 trillion. Gooogle answers that nicely:
[google.ca...]

Cobol worldwide spending at 3 trillion? I doubt that Cobol spending worldwide is 25% of US GDP.

70 percent of the world's data is processed by COBOL.

This is a very vague statement and I doubt that is the case. Database access over the net is a huge part of "data processing" worldwide and many/most databases accessed over the net are not using Cobol to access them. For example: Amazon, Ebay etc.

roblaw




msg:1579186
 8:37 pm on Sep 19, 2005 (gmt 0)

Webwork,

If it hasn't already been mentioned, you should consider reading the book "Database Design for Mere Mortals". It will give you a strong enough footing to be able to communicate effectively with your programmer(s).

graywolf: Loved the reference to the "My First Database" article at Webmonkey. That was my first intro into DB design.

roblaw

ionchannels




msg:1579187
 12:34 am on Sep 20, 2005 (gmt 0)

Yawn... lots of self-importance here... DB design is not difficult, nor is building or maintaining the database. Mysql will do most of what one needs and the query language, though not as powerful, is easily learned and even, dare I say, mastered. Couple that with a knowledge of PHP, and one can create a website as functional and impressive as even the most well-funded startup...

lexipixel




msg:1579188
 2:45 am on Sep 20, 2005 (gmt 0)


I believe I need a database, but how do I start the process? Are there standard questions that a competent db programmer will ask me?

-Webwork

Question #1: How many records will the database ultimately contain?

If the answer is "no more than X", and X is 100, 200, 500 or even a thousand), the solution will be different than if you answered "millions" or "I don't know".

Question #2: What fields and types of data do you need in each record?

STRING (specify length, acceptable chars)
DATE (specify date format / acceptable range)
INTEGER (specify range / negative allowed?)
DECIMAL (how many places of precision needed)
BOOLEAN ("Y/N?", (Yes/No, Off/On, 0/1) notation?

In many cases you can simply treat all fields as (text) strings.

Question #3: Will this database tie to any other databases?

After you answer (at least) these three questions you can talk about database design.

I have several customers who have told me they "need a database" and found they didn't need much more than a formatted text file and a perl script to search through it.

...my $0.02

paybacksa




msg:1579189
 8:16 am on Sep 20, 2005 (gmt 0)

Jumping in late...

You need to know what you want the site to do before you can draft a database schema (the design of the database infrastructure). This usually happens on two levels.

First, the basic concept of the site will define a whole bunch of the db schema if your developer is any good. Much of this stuff has been done before, and there are many conventions/best practices. You should not have to think of it all; much if not most of it should be done by the database designer as a matter of best practice even if you don't ask for it.

Second, your very specific desires for your site will (perhaps) highlight specific things the database schema will have to accommodate. Think of this as where your ideas may actually be innovative from an established best practices perspective. Or your desires may simply set priorities that override defaults upon which the developer may have based her starting assumptions.

I believe a client can stay entirely within his own head (not try to be a database expert) and effectively guide a database designer/code developer if the communications are good. Draw pictures, mock up every page of the site, work through all the details of how it should flow/what it should do and hire "A" quality people and you don't need to study databases or learn programming.

The "A" quality people will deliver for you, where lesser quality people may be inclined to give you "exactly what you asked for" while charging for every additional change order.

Good luck.

dwhitten




msg:1579190
 3:14 pm on Sep 20, 2005 (gmt 0)

Get someone with experience in data-modelling, and who has designed databases before, and knows what they're doing. Then you shouldn't have to worry about all the details other than making sure you have a good list of requirements for what you want the whole system to be able to do. A good database person will ask the questions that are needed.

Anyone can create database tables, but it does take some knowledge to design a complicated database system.

My 2 cents!

Deb

surfin2u




msg:1579191
 4:15 pm on Sep 20, 2005 (gmt 0)

On the question of the importance of COBOL, I would like to ask how many universities offer COBOL programming courses as an important language in their computer science curriculum? More to the point, my reason for bringing up COBOL was my assertion that managers, who though COBOL would relieve them of needing programmers, realized that it didn't because managers usually can't program.

I do believe that people can learn to design and build simple databases and if you're a do-it-yourselfer then have at it. Here's an analogy. If you're sick, you may first try to cure yourself with a few things, but if they don't work, then you go see the doctor. Nothing wrong with that in my opinion. You understand your limitations and act within them. No problem.

It's when you violate the Clint Eastwood rule, "A man has got to know his limitations" that you get in trouble.

The problem with building your own database solution for your business is that when it doesn't work out, the situation can be seriously bad. Your business is growing quickly and your system won't do what you need it to. You're forced to resort to alternatives that might be quite painful. Just like when you wait too long to go to the doctor. It can kill you, or just be a headache, depending on how lucky you are. Are you feeling lucky?

volatilegx




msg:1579192
 5:18 pm on Sep 20, 2005 (gmt 0)

Let's stay on topic. Comments/questions about COBOL belong in another thread.

This 33 message thread spans 2 pages: 33 ( [1] 2 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / Databases
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved