[AccessD] Primary keys and entry points (was: Learning .Net -- PHP Instead?)

Jim Dettman jimdettman at verizon.net
Wed Jun 24 18:40:56 CDT 2009


  The profox list currently has a discussion running on the use of GUIDs as
surrogate keys.  It seems quite a few developers there have been using them
for sometime.

Jim.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil
Salakhetdinov
Sent: Wednesday, June 24, 2009 7:11 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Primary keys and entry points (was: Learning .Net --
PHP Instead?)

Hi Gustav,

Yes, "the single exit point is not a B/W discussion" (as most of the others
we keep under this thread) - did I say I'd not use the same construct you
presented in your posting? - in fact I mean I can use both depending on how
I will come to my solution/what case I will program first...

As for "PK great debate" - I'm now just guessing that ADO.NET Entity
Framework could break one of the last and most "rigid" of my habits to use
AutoNumber/Identity PK for all and every tables, and not only for lookup
tables but also for relation tables: using of AutoNumber/Identity PK comes
IMO mainly from technical/common sense (but again based on technical
issues(?)) reasons, and ADO.NET Entity Framework, I guess, can "annul all
that reasons", and cascade update can help to solve "fragile" natural
primary key issue (hear, hear (JC ? :)) - cascade update is the greatest
evils - and I do not use it currently...). And there could be GUID field
introduced instead of Autonumber/Identity PK - but just to keep "object
identity" in this becoming so distributed world with myriad times replicated
data objects...

--
Shamil

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Thursday, June 25, 2009 1:48 AM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Primary keys and entry points (was: Learning .Net --
PHP Instead?)

Hi Shamil

You may do so but why would you? If you don't have an Id as the primary key
of the underlying table, you will have to construct one, and I just don't
think it is worth wasting time on this when applying an Id resolves the task
in a second. I even apply the Id to a table of countries because the ISO
codes _may_ change (rarely I know) but - more importantly - I don't have to
decide for using the alpha or the numeric ISO code as the key.

As for the single exit point, I don't think this a B/W discussion. Sometimes
it is convenient to drop out at once when a simple condition is not met as
in the example from the link:

    if (account == null) return;

at the top of a method.

However, I wouldn't put this somewhere many lines down as it is impossible
to read; if you find such a line you will have to study every other part to
look for similar lines. Thus, I much prefer the traditional construct:

    if (account != null)
        { 
          // 20 lines of code
          // (that are totally irrelevant if account is null)
          // later...
        }
    // and out we pop

This you can browse in a split second, and should you later need to apply
some code for the case (account == null) it is very easy to insert that
following an "else".

/gustav


>>> shamil at smsconsulting.spb.ru 24-06-2009 20:41 >>>
<<<
Natural PKs on the other hand...
;)
>>>
Hi John,

Do you mean "great PK debate"? :)

I feel that I will soon give up even "use Autonumber/Identity field for
every table" principle, which I do strictly follow for many years, in the
case ADO.NET Entity Framework will become my main Data Access/Manipulation
technology...

It's unbelievable...

--
Shamil


-----Original Message-----
From: accessd-bounces at databaseadvisors.com 
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, June 24, 2009 8:16 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Learning .Net -- PHP Instead?

And I contend that if the garbage collector is airtight then the need is
less.

VBA OTOH has a garbage collector that belongs to a union, it only works on
Mondays, Wednesdays, the 
third Fridays and never on holidays.  Unless of course it is just out on
strike...

I think from reading the articles and the comments underneath that there is
no consensus.  An 
opinion is an opinion is an opinion.  Man is a rationalization machine and
while you can rationalize 
as many exit points as you want, I can rationalize only a single exit point.

Natural PKs on the other hand...

;)

John W. Colby
www.ColbyConsulting.com 


Shamil Salakhetdinov wrote:
> Hi Arthur and Charlotte,
> 
> I used to use the same "one exit point" principle over the years
(especially
> in my VBA programming) but I must note it's becoming obsolete nowadays: I
do
> not use it almost at all anymore in my C#/VB.NET development.
> 
> Have a look what is the reasoning behind this "new approach" to not bother
> about "one exit point" principle: 
> 
> http://ubuntuforums.org/showthread.php?t=631745 
> 
> http://discuss.joelonsoftware.com/default.asp?joel.3.325456.34 
> 
> Everything seems to be changing in programming these days but one who has
> been in programming for some time can rather clearly see we're "just"
> getting repeating/rethinking of "good old habits" but on higher current
> level of evolution spiral of computer science, programming methods and
> practices... 
> 
> Thank you.
> 
> --
> Shamil



-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4186 (20090624) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru


 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4186 (20090624) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru
 

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list