Re: OO vs. RDB challenge

From: Kurt (kurbylogic_at_hotmail.com)
Date: 03/25/05 

Date: Fri, 25 Mar 2005 02:27:02 -0700

"Costin Cozianu" <c_cozianu@hotmail.com> wrote in message
news:3ag02kF6b3vgoU1@individual.net...
> Kurt wrote:
>>>Your code in both solutions avoids the deadlock by choosing to expose
>>>users to inconsistent data.
>>
>>
>> Wrong, Policy.Current is always valid, modifications to that object
>> cannot affect another user until Policy.Current is replaced, the new
>> policy is ensured by to be valid by the property set method.
>>
>
> Hmmm, interesting. Are you trolling or simply incompetent?
>
> Let's assume that in the heat of trying to "prove" something you don't use
> your best judgement, and in reality you can have more objective
> assessments about your code.

You are the one that made the absurd claim I'm just showing you how simple
can be. The only constraint not met yet is the better than linear search
time, a call to Array.Sort or a SortedList and you'll have no problem
getting better then linear search time, all your constraints would be met.

So as far as an objective assesment, is this the way that I would do it?
The short version hell no I believe in concepts such as encapsulation, first
version might be okay in the simplest of requirements. There are few things
that need improvement to make it all that useful in a practical application.
Conflicting updates are not checked (not a constraint, yours doesn't do it
either, I'm sure you wont believe me till I actually write a couple SQL
scripts to demonstrate it but anyways) and copying the entire policy
structure on every get/set is not the most efficient way to go about it... a
few hundred users it would be fine, modification of a million records
(unlikely as that is for users and groups) would be rather slow. However,
without an application driving the requirements there is no need for this
code to exist, and thus for this pointless excersise, the *simplest thing*
is good enough. For all practical purposes its as worthless as yours. You
are the one who was *insisting* on not adding unnecessary complexity, so
there it is the simplest thing that could work.

>
> But if you see nothing wrong with your design, please let us know how the
> client context, say the UI, goes about (1)creating a new group, (2)
> removing a group, (3) creating a user (4)removing a user in the system.
>

Since all the members are public, nothing is stopping the client from modify
the array (reallocation probably necessary unless you do something clever
like allocate a larger array in the first place). Programming 101, if you
can't figure it out use the slightly longer version its has methods that do
this for you. It's not much different then updating or inserting into a
table.

I'm not against databases, I use them all the time.... the "complexity" of
OO isn't the reason. Most of our reports are unfortunatly written in the
database, the sprocs involved are a around a couple thousand lines of code
(several thousand lines if you include code for the functions used), they
are far more complex then OO code that creates and manipulates that data in
the first place, sub-accounts need to be rolled up to the parent, currency
conversion must be performed, and a number of other rather trivial functions
in the OO application become massive chucks of sql code. The only reason
they are implemented in the database is because it is too inefficent to send
several hundred thousand records to the application for processing. Most
database objects have simalar OO representation in the application, if the
database only provided query services and persistance or memory size wasn't
an issue, then in my opinion a database would just add unecessary complexity
to the application... despite many-many relationships which do exist in our
application, they are the least of my concerns. Your claim to me is
completely absurd, not to mention rather irrelevant as persistance and
memory size are still valid application concerns. I didn't expect I would
have go as far as explaining array manipulation from programming 101. I
don't know why I'm wasting my time, other then becuase of the utter
stupidity of your first comment, I guess I enjoyed watching you publicly
display your stupidity. I know that is rather small of me, but I'm loosing
interest and this pointless code isn't worth defending, its simplest thing
that could work, no more no less.

- Kurt

Relevant Pages

  • Re: OO vs. RDB challenge
    ... > complexity of mapping database tables to objects is useful only if the ... You would use the DBMS. ... > need to be thread safe because a thread can only get an instance of it ...
    (comp.object)
  • Re: confusing relationships
    ... Even if some of the people in your database will never be policyholders, ... Do some of these named spouses also have multiple spouses whom you need ... Is exactly one insured person named on each policy? ... ..i have another table which has all policy types (time periods ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Getting database value into a rule policy
    ... You need to have a variable of type Dataconnection ... instances in the composer or orchestration. ... I don't see where I can send a database ... but my policy only works in testing. ...
    (microsoft.public.biztalk.general)
  • RE: Database Corruption after Exchange SP 2
    ... I repaired my Exchange database successfully and I can perform backups ... A conflict in Group Policy can cause these events to occur. ... Windows XP to configure domain policies, you may find that the policies do ...
    (microsoft.public.windows.server.sbs)
  • Re: OO vs. RDB challenge
    ... >>language, and especially with regards to distinguishing positional ... > complexity of mapping database tables to objects is useful only if the ... > public static bool IsUserInGroup(string user, string group) ...
    (comp.object)