paul c wrote:
> dawn wrote:
>
>> ...
>>
>> I'm presuming no such thing. I'm talking about the model of the data
>> needed for the screen. To answer David's question too, if you were to
>> prepare a diagram of your choice, perhaps UML these days, of the
>> logical data model that a software application needs for interfacing
>> with the database and the logical model it needs for the UI, choosing
>> the same entities and attributes to model, your UML diagrams would be
>> different. Given there is an industry arising from this along with the
>> OO-RM impedence mismatch, I think this is rather well established.
>>
>> We take data in from a screen as strings, change them to objects based
>> on specifications in code or parameter data, and then to relations
>> based on specifications in code or parameter data, with each process
>> validating everything along the way. The RDBMS takes those relations,
>> validates with constraint logic likely written in a different language
>> than the other validations, and turns the data into strings to be
>> stored.
>>
>> That doesn't seem efficient in either machine or people time for both
>> development and maintenance activities. Or am I missing something?
>
>
>
> Dawn, I think you are on the right track, but I think you must throw out
> some of the conventional lingo/arguments before it goes anywhere. F...
> (you know what i mean) the 'modelling', etc. The data has already been
> modelled. Just my 2 cents.
The screen-data? How?
BTW why is this still in a NULL thread?
Received on Mon Jan 09 2006 - 12:09:44 CST
