Re: storing survey answers of different data types
Date: Wed, 29 Apr 2009 20:09:55 -0300
Message-ID: <49f8de44$0$23761$9a566e8b_at_news.aliant.net>
lawpoop wrote:
> On Apr 23, 12:48 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
>>It depends on your requirements. For one set of requirements, >>"convenient" means in the dbms. For another set of requirements, >>"convenient" means in a text file somewhere. For another set of >>requirements, "convenient" means the first column of a spreadsheet. For >>another set of requirements, "convenient" means written on paper in a >>carefully guarded box to be gathered up after use and secured again.
>
> Okay. I'm going to say this with the assumption that user requirements
> are not a formal language like math, programs, or DDL.
They are not; although, things like ORM use formalized english sentences in analysis.
> How does one get from the sloppy human language to a DDL? What kind of
> requirement says to you " This calls for a database?" Just simply
> saying "We want this done in a database"?
>
> You mention different things being more convenient on paper, on a
> spreadsheet, etc. How does one get out of convenience into "must be"
> or "really won't work if you try it that way"?
Let's break this down for a moment. Consider three levels of discourse: conceptual, logical, physical. Conceptual deals with information at a human level where it is not necessarily encoded suitably for mechanical processing. Logical deals with data, information encoded suitably for mechanical processing in some sort of symbolic formalism. Physical deals with whatever base services you have available--perhaps physical hardware or some very thin abstraction of same.
Designing a system requires addressing all three levels of discourse. Within that, some small parts of the logical and physical levels have some math or science behind them. The rest is art.
"Really won't work that way" is only constrained by the physical properties of our universe. We cannot create a general solution to the halting problem no matter how much we might want to. But at the same time, google can search through mindbogglingly huge gobs of text and deliver useful results in less than 300 ms over my dial-up connection.
One can state google's requirements quite simply. Delivering them is another matter.
One cannot really get to "must". Hominids survived 5 million years before altavista came along, and most of us stopped using it when better alternatives came along.
If you have requirements for reliability, security, logical derivation, concurrency, scalability, correctness etc. that dbmses handle well, then I suggest a dbms suits your requirements.
>>Given that databases did not exist for 5 million years of human >>evolution and we all managed to get here, I would not argue for the >>necessity of putting anything in a database.
>
> Okay. I think I see what you're doing here. Databases are not
> *necessary* for anything. What sort of requirements would cause you to
> say "this is optimally done in a relational database"? What's an
> example?
Reliability, security, logical derivation, concurrency, scalability, correctness etc.
>>>Can you help me understand how requirements help me decide what >>>belongs *necessarily* in the database, and what doesn't? >> >>See above at "evolution".
>
> Okay, can you help me understand why, in the model that Roy proposed,
> he chose to say that certain things belonged in a table, certain other
> data belonged in multiple tables, where to keep a template --" We
> don't store the template anywhere--maybe we should but we don't. "
> None of it was strictly necessary. Why did he make the proposal that
> he did? How do we go from requirements to a DDL?
He was only working from a tiny subset of your requirements: The requirement to represent answers to diverse questionnaires with diverse answer types. Received on Thu Apr 30 2009 - 01:09:55 CEST