Prev: CURSOR_STATUS question
Next: Add Primary Key enforced with Existing Unique Index: How To
From: Iain Sharp on 28 May 2010 04:26
On Thu, 27 May 2010 17:06:14 -0700 (PDT), --CELKO--
<jcelko212(a)earthlink.net> wrote:


>
>What was the silly, totally non-relational "index_id" about? Do you
>know what a key is in RDBMS? Where would it exist outside of physical
>storage? How would you validate or verify it?
>

Good question, reminds me, I am still looking for the simple, easy to
access, non-invasive, unique primary key for a human being that I can
get instantly, is 'industry standard' and verifiable.

You promised me there was one.

Any idea what it is yet? Because I'm still having to use and ID field,
and it must be warping the fabric of reality to do so.

Iain
From: Iain Sharp on 28 May 2010 05:18

Stealing a bit of the setups from Joe's post, here's a solution. I
suspect it will scale relatively poorly.

---Firstly some setup;

CREATE TABLE #Population
(person_name VARCHAR (35) NOT NULL PRIMARY KEY);

INSERT INTO #Population
VALUES ('A');
INSERT INTO #Population
VALUES ('B');
INSERT INTO #Population
VALUES ('C');
INSERT INTO #Population
VALUES ('D');
INSERT INTO #Population
VALUES ('E');
INSERT INTO #Population
VALUES ('F');
INSERT INTO #Population
VALUES ('G');
INSERT INTO #Population
VALUES ('H');

create table #relationships
(index_id integer , p_name varchar (35) , friendname varchar (35))

insert into #relationships
values(1,'A' , 'B');
insert into #relationships
values(2, 'A' , 'C');
insert into #relationships
values(3, 'B' , 'A');
insert into #relationships
values(4, 'B' , 'D');
insert into #relationships
values(5, 'C' , 'A');
insert into #relationships
values(6, 'C' , 'E');
insert into #relationships
values(7, 'D' , 'B');
insert into #relationships
values(8, 'D' , 'E');
insert into #relationships
values(9, 'E' , 'C');
insert into #relationships
values(10, 'E', 'D');
insert into #relationships
values(11, 'E', 'F');
insert into #relationships
values(12, 'F' , 'E');
insert into #relationships
values(13, 'G', 'H');
insert into #relationships
values(14, 'H', 'G');

---- Right, now the query (queries)

-- First, set up a temp table.
create table #friends
(friend varchar (35) not null primary key);

--Second, 'prime the pump' by inserting the first friend.

insert #friends values ('A')


--Now, repeat until we have found no new friends.
while(@@rowcount > 0)
begin
insert #friends
select person_name
from #Population
inner join #relationships on friendname=person_name
inner join #friends on friend=p_name
where not exists (select * from #friends where friend =
person_name)
end

select * from #friends

---- Done

This assumes a hierachical relationship in friends (A can invite B,
but B can't invite A.)

To make the relationship an equivalence, we would replace the select
inside the insert with the following

select person_name
from #Population
inner join #relationships on friendname=person_name
inner join #friends on friend=p_name
where not exists (select * from #friends where friend =
person_name)
union
select person_name
from #Population
inner join #relationships on p_name=person_name
inner join #friends on friend=friendname
where not exists (select * from #friends where friend =
person_name)
From: Iain Sharp on 1 Jun 2010 05:27
On Fri, 28 May 2010 09:39:54 -0700 (PDT), --CELKO--
<jcelko212(a)earthlink.net> wrote:

>>> I am still looking for the simple, easy to access, non-invasive, unique primary key for a human being that I can get instantly, is 'industry standard' and verifiable. You promised me there was one. <<
>
>WHICH industry? Which role are they playing in the Universe of
>Discourse? What is the degree of risk you can accept? What cost of
>verification you can accept?

Steel sales. I've got a guy on the end of the phone, works for Smiths
Inc, name's John Jones, "No not that John Jones, I just started
working here. Yeah, there's two of us. Small world isn't it? "

But, to be fair, anything that will work with a member of the general
public, over the phone.

>
>Do you not listen or really don't know understand basic data modeling?
>There is no Kabbalah number, and the count of physical insertion
>attempt on one installation of one product on one machine (aka
>IDENTITY) is not relational.
>

It's just somtimes the best we've got.
Not everything has a 'real world' short uniquifier. In fact in my
experience MOST entities do not have a 'real world' short uniquifier.
Every example you have come up with so far has been either lacking in
specificity (steel standards are not steel products) or been worth
collecting. (I will not give you my SSN so I can buy a bit of steel).

>As an aside, my favorite identifier for companies is the DUNS. Free to
>obtain, universally used, embedded in accounting systems, etc. I
>talked to D&B a few weeks ago and found out that they are up to 160
>MILLION companies in the US; no idea what the global figure is.
>
>I then had a complaint that this is not comprehensive enough from a
>troll. It is a game .. literally, in the Transactional Analysis sense
>of a game. It is called "Yes, but .." The goal is to raise endless
>objections, no matter how trivial, and not to find solutions to a
>problem.
>

Well, since the troll WAS me :) .... Neither of the two companies I
work for are DUNS registered, it is not free to access in the U.K., my
customers will have no idea what the DUNS number is for their company
(if they even have one). Making it a really poor choice for U.K.
companies. (Particularly SMEs)

I seem to recall your solution to there not being a universal coverage
for DUNS numbers was to store fake ones for where you didn't know the
answer. Poor, really poor, fake data is the worst kind of answer to
any storage problem. Surely the generic answer to 'I don't know' is to
store NULL.

>I just saw a TV ad for a paternity home test kit; that used to be lab
>work. Fujitsu is working on a cheap electronic DNA system. In 3 to 5
>years, they hope to have a device that takes your DNA and it matches
>you to a digital signature. The goal is a device where you put your
>finger in a hole and an encrypted smart-card in a slot. The use would
>be confidential medical records and other very secure applications.
>
>And to head off the nitpicking you love to do, read:
>
>http://www.freerepublic.com/focus/f-news/1986041/posts
>
>Sorry, twins have different DNA.

So, when your DNA is cheap and easy to read.
1. Will you be prepared to give me your DNA code (or for that matter
your SSN) to buy a TV?
2. How long will the telephone conversation where you read it to me
take?

And seriously, the answer I should take to my boss, who wants a CRM
database now is "Wait a few years, Joe says I can't code the database
until DNA reading becomes universal."?


3. Other than storing otherwise useless data in a large space on my
hard drive, what use will it be to me?
From: Iain Sharp on 3 Jun 2010 04:02
On Wed, 2 Jun 2010 16:16:49 -0700 (PDT), --CELKO--
<jcelko212(a)earthlink.net> wrote:

>>> Steel sales. I've got a guy on the end of the phone, works for Smiths Inc, name's John Jones, "No not that John Jones, I just started working here. Yeah, there's two of us. Small world isn't it? " <<
>
>"Okay, John, what is the purchase order number?" Smiths Inc has an
>account, therefore a DUNS (you do check credit before you send steel
>to people on a phone?)
>

That is not storing John as a contact in the contacts database for
re-use or analysis.

>>> But, to be fair, anything that will work with a member of the general public, over the phone. <<
>
>"Okay, what is your credit card number?" The role of a purchaser is
>that they pay. You do not give a damn as to the person behind. You
>assume that risk of a bad card (do people steal steel?) and buffer for
>it.
>

But I'm paying by account. I don't want to give you my credit card
number.

>>> It's just somtimes the best we've got. <<
>
>Never. Have you looked at a POS receipt? It has a timestamp, register
>number and store number at least. I can do some tracking with that
>metadata What can you do with an IDENTITY (i.e non-deterministic
>PHYSICAL order of insertion in the PHYSICAL dat into ONE and only one
>machine in a proiprietary product).
>



>>> Neither of the two companies I work for are DUNS registered, it is not free to access in the U.K., my customers will have no idea what the DUNS number is for their company (if they even have one). Making it a really poor choice for U.K. companies. (Particularly SMEs) <<
>
>Are you saying that Dunn & Bradstreet does not do business in the UK?
>Wow. This is like when Rogerson was saying that the UK does not use
>VINs.
>

No, I'm saying that their business model in the U.K. means that it is
not FREE to find out a companies DUNS number, in fact, it seems to be
quite difficult.

PCI Systems Ltd, Sheffield. Have fun.

>>> I seem to recall your solution to there not being a universal coverage for DUNS numbers was to store fake ones for where you didn't know the answer. Poor, really poor, fake data is the worst kind of answer to any storage problem. Surely the generic answer to 'I don't know' is to store NULL. <,
>
>What I proposed are called "shop numbers"; they in EAN/UPC/GTIN for
>example. These standards allow for locally created numbers for things
>that are made in the shop (bakery, deli, etc).
>

I.e. fake data. Unverifiable, and corrupting the integrity of any real
data you want to store. Lovely.

>>> 1. Will you be prepared to give me your DNA code (or for that matter your SSN) to buy a TV? <<
>
>For my medical data, sure. But for a TV, you can live with my credit
>card number (which may go back to DNA at a trusted source). After
>all, it is secured by my body organs :)

Your credit card number is not a unique identifier of you as a buyer.
I have three credit cards, and two debit cards, one to a joint
account.
So, settle for less because Joe doesn't like the only solution?

Iain
From: Dooza on 3 Jun 2010 04:16
On 03/06/2010 09:02, Iain Sharp wrote:
>>>> 1. Will you be prepared to give me your DNA code (or for that matter your SSN) to buy a TV?<<
>>
>> For my medical data, sure. But for a TV, you can live with my credit
>> card number (which may go back to DNA at a trusted source). After
>> all, it is secured by my body organs :)
>
> Your credit card number is not a unique identifier of you as a buyer.
> I have three credit cards, and two debit cards, one to a joint
> account.
> So, settle for less because Joe doesn't like the only solution?

And if its a business credit card there could be loads of people using it.

Celko = Fail

No more NNTP = No more Celko

Dooza
 |  Next  |  Last
Pages: 1 2
Prev: CURSOR_STATUS question
Next: Add Primary Key enforced with Existing Unique Index: How To