Re: best way to store checkbox + text-entry fields

Eep² wrote:

> Jonathan Leffler wrote:

 >>Eep² wrote:

>>[...major snippage...]
>>>http://tnlc.com/eep/compare/gameform.html

 >>>http://tnlc.com/eep/compare/relations.jpg  >>>http://tnlc.com/eep/compare/relations3.gif

 >>>http://tnlc.com/eep/compare/relations4.gif  >>

>>The stuff in relations.jpg appears to be trying to capture different
>>peoples views of the same game; the stuff in relations3.gif and
>>relatsions4.gif appears to be trying to present a single
>>(authoritative) view of the game. You need to decide which is the way
>>you want to progress - both designs are plausible, but they are very
>>different.
>
> Well, that's just it: I don't know HOW to decide which is the way I
> want to progress since I keep getting told different things by
> different people and have never created a database before so it's all
> VERY confusing and contradictory!

I suspect that it is confusing in part because you have not yet clearly articulated to yourself exactly what you are after. And on that point, no news goup can help you -- you have to know what you are seeking to do. My impression from poking around some of the other links you have given is that you will largely be presenting one view of a given games, albeit with information provided by multiple sources. I may be completely misreading this, of course. Now, I can see that there are two types of external source of information: those that are qualifying an already described game and those that are describing a new game. You may have to provide alternative input systems, and possibly alternative sets of data tables, for these types of description, which are then used to populate (modify) the single authoritative view of each game.

What do you want to happen if someone tells you "Balderdash - Tomb Raider doesn't use XYZ engine; it uses PQR. Further, it does this special effect and not that one or that other one as you claim." You probably don't want this information placed on your site automatically, certainly not as a definitive statement, until you've had a chance to review what was said. Or would you?

So, you need to think very carefully about what you really want done, and how much of it will be done automatically versus how much will be manual. I guess the existing system is all manual. You need to think how information will be submitted to you, and how it will be processed. You should look at how the information is currently submitted and how it is currently processed. All those steps where you take a wild leap of the intellect to divvy up the comments have to be tamed and made systematic.  

> If you look at http://tnlc.com/eep/compare/table.html you'll see
> the

end result of what I want to achieve, only allowing people to choose which games/features they want to compare. It's all explained on the main page at http://tnlc.com/eep/compare/. I just don't know how to proceed. :/

I've looked - I see after a fashion what you have (but I don't play 3D games, so I'm not much the wiser). I wouldn't particularly want to put that lot into a database - especially not with the features that span multiple versions of the game. Ouch! That's not to say it can't be done; it can. But it won't be easy.

> Genres are only ONE (1) thing I want people to be able to add to.
Just look at the game form (see above for link) to see everything I want to allow submission to. I need help designing the database accordingly.

It will be harder. Don't forget, people misspell things, for example, so if someone decides to enter a genre 'stimulation', something has to decide whether this is a valid genre or should actually be treated as 'simulation'. Issues like this can send you screaming on your way if you're not careful.

> Thanks for your response, but I really need more detailed information.

OK; and that is unlikely to be directly available from a news group. We will help by proffering advice on alternatives you present, but you still have to know more or less what you want to be able to discriminate between the options presented.

Pure gut feel: you need to create a relatively simple system that you would regard as incomplete by comparison with what you'd like, but something that is attainable. It needs to be open-ended enough to allow for significant adhocery in the data entry, but you will manually clean this data to start with. As you get more experienced, you'll add more to the system, gently reorganizing what you already have. In half a dozen iterations, you'll get close enough to what you currently have to be temporarily content. But you'll also have enough experience by then to know your limitations and your system's limitations, and you can add the extra features you really wanted from the start. As things stand, you are a bit like a 15-month toddler trying to run a marathon - you simply don't know enough about it all to know what to do. So, you need to start with some baby steps, and then as you become more experienced, you can get the results you want. Or you can buy in the experience you are missing - consultancy or whatever. OK; I'm pretty sure that's completely untenable, so you will need to obtain the experience yourself. And I think you're trying too hard to do everything from the start.

-- 
Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler_at_earthlink.net, jleffler_at_us.ibm.com
Guardian of DBD::Informix 1.00.PC2 -- http://dbi.perl.org/