Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

how to fetch records from multiple tables Expand / Collapse
Author
Message
Posted Thursday, December 27, 2012 5:51 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Thursday, July 17, 2014 12:46 PM
Points: 91, Visits: 143
i have Demo,elections and electionshist tables where i should neglect the pepole who have status='t' from demo table and for those who are not neglected i should check whether electionstartdate is null and electionterminationdate is not null from election table then for these people i should check in electionhist table that whether the person has electionstartdate is not null(the value must be fetched from the top most load.
In demo and election tables we have nearly 50000 -60000 records but in electionhist tables nearly 10000000 records are there.
Can anyone please suggest me in pulling records when a situation prevails like this....i am able to do it but it takes a longer time....i need to pull it in mins.
I have given you the entire picture of the situation..Pleas go through this and let me know your suggestions.Thanks in advance

CREATE TABLE Demo
(
Sno bigint,(PK,IC)
GId bigint,(FK_clt)
lid bigint,(Fk_ld)
Slid bigint,(Fk_Sld)
eno varchar(15),
status varchar(5)
)INDEX(Gidempno)

CREATE TABLE Election
(
SSno bigint,(PK,IC)
Sno bigint,(FK_demo)
GId bigint,(FK_clt)
lid bigint,(Fk_ld)
Slid bigint,(Fk_Sld)
eno varchar(15),
Type varchar(6),
electionstartdate datetime(8),
electiontermdate datetime(8)
)
INDEX(Gidlidtype)

CREATE TABLE Electionhist
(
SSSno bigint,(PK,IC)
SSno bigint,(FK_election)
Sno bigint,(FK_demo)
GId bigint,(FK_clt)
lid bigint,(Fk_ld)
Slid bigint,(Fk_Sld)
eno varchar(15),
electionstartdate datetime(8),
electiontermdate datetime(8)
)

Create table clt
(
sid int,[PK,iC]
gid bigint,
clid bigint
)

Create table ld
(
Sid int,[pk,ic]
lid bigint,
gid bigint
)

Create table sld
(
sid int,[PK,IC]
slid bigint,
lid bigint,
gid bigint
)

PK->primary key
IC->Identity column
FK_XXX->Foregin key_Refereneced table


Pic of the table

Demo
Sno Gid Lid Slid Eno Status
6 123 9876 546 765 A
7 123 9876 546 546 R
8 123 9876 546 321 T

Election
Ssno Sno Gid Lid Slid Eno type ElectionStartdate Electiontermdate
10 6 123 9876 546 765 S NULL 3/2/2012
11 6 123 9876 546 765 L NULL 3/2/2012
12 7 123 9876 546 546 S 3/2/2012 NULL

Electionhist
SSSno Ssno Sno Gid Lid Slid Eno type ElectionStartdate Electiontermdate
25 2 1 123 1000 23 765 S NULL 3/2/2010
26 3 1 123 1090 25 765 S 9/9/2009 NULL
27 4 2 123 1090 25 765 L 9/9/2009 NULL
28 5 3 123 1101 87 321 S NULL NULL
29 8 4 123 1190 89 765 S 9/9/2009 NULL
30 9 5 123 1190 89 765 L 9/9/2009 NULL

Query what i have tried:

select seh.GID , seh.eno, seh.type, Max(seh.LID) LID,MAX(seh.slid) Slid
FROM dbo.clt g WITH(NOLOCK)
CROSS APPLY(select seh.gid,seh.LID,seh.Slid,seh.SSN,seh.type from dbo.Electionhist seh WITH (NOLOCK)
INNER JOIN dbo.clt g with(nolock)
on g.GID=seh.GID
AND g.ClID=90
INNER JOIN dbo.Ld l with(nolock)
on l.GID=g.GID
and l.LID=seh.LID
INNER JOIN dbo.SLd sl with (nolock)
ON sl.gid=l.gid
AND sl.LID=l.LID
AND sl.SLID=seh.SLID
INNER JOIN dbo.demo s WITH(NOLOCK, INDEX(IX_demo_GIDeno))
ON s.gid >'0'
AND s.eno > '0'
AND s.GID=sl.GID
AND s.GID=seh.GID
AND s.eno=seh.eno
AND s.LID=sl.LID
AND s.SLID=sl.SlID
AND s.Status <>'T'
INNER JOIN dbo.Election se WITH (NOLOCK,INDEX (IX_Election_GIDLIDtype))
ON se.GID >'0'
AND se.LID > '0'
AND se.PlType in('S','L')
AND se.GID=s.GID
AND se.GID=seh.GID
AND se.LID=s.LID
AND se.SLID=s.sldid
and se.electionStartDate is null
and se.electionTerminationDate is not null

WHERE seh.gid >'0'
AND seh.LID > '0'
AND seh.type in('S','L')
AND seh.electionStartDate IS NOT NULL
AND seh.electionTerminationDate IS NULL
)
group by seh.GID , seh.eno, seh.type


Expected Result
GID eno Type LID Slid
123 1190 89 765 S
123 1190 89 765 L

If you are not clear with this please let me know i will explain you more.
Post #1400763
Posted Thursday, December 27, 2012 7:37 PM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Friday, December 12, 2014 8:24 PM
Points: 1,945, Visits: 3,173
If you are not clear with this please let me know I will explain you more.


Why did you invent your own language? We would have to translate it into SQL DDL to help you! Please learn the ISO-11179 rules for data element names. Many of your data element names are too vague to be useful. What kind of “status”? Marriage? Employment? I will guess “voting_status”

I guess PK means “NOT NULL PRIMARY KEY”, but a good SQL programmer never uses IDENTITY for a key. What kind of entities are an “s”, “l” and “g”; only entities have identifiers! The rest of your private database language is full of vague names! Type? Blood?

T-SQL does not have “DATETIME(8)”, but we do have DATE. We also use the ISO-8601 date format, not local dialect.

Are you in the right forum?

If you want help, then post real DDL, and include INSERT INTO testaments, not ASCII pictures.


Books in Celko Series for Morgan-Kaufmann Publishing
Analytics and OLAP in SQL
Data and Databases: Concepts in Practice
Data, Measurements and Standards in SQL
SQL for Smarties
SQL Programming Style
SQL Puzzles and Answers
Thinking in Sets
Trees and Hierarchies in SQL
Post #1400776
Posted Thursday, December 27, 2012 11:27 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 1:15 AM
Points: 13,633, Visits: 11,504
CELKO (12/27/2012)


Please learn the ISO-11179 rules for data element names.


Which can be downloaded where?

CELKO (12/27/2012)

I guess PK means “NOT NULL PRIMARY KEY”, but a good SQL programmer never uses IDENTITY for a key.


That's hilarious. Care to explain why?




How to post forum questions.
Need an answer? No, you need a question.
What’s the deal with Excel & SSIS?

Member of LinkedIn. My blog at LessThanDot.

MCSA SQL Server 2012 - MCSE Business Intelligence
Post #1400800
Posted Thursday, December 27, 2012 11:49 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 2:16 AM
Points: 2,840, Visits: 3,983
Also please post exec plan(people would prefer graphical plan ) along with index definition too as index play significant role to pull out the data faster.

-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done
Post #1400803
Posted Friday, December 28, 2012 9:08 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 3:05 PM
Points: 13,320, Visits: 12,804
You also might want to read up on the NOLOCK hint. It can produce all sorts of really difficult to replicate bugs. It can (and will) miss some rows and even return duplicates.

http://blogs.msdn.com/b/davidlean/archive/2009/04/06/sql-server-nolock-hint-other-poor-ideas.aspx

http://www.jasonstrate.com/2012/06/the-side-effect-of-nolock/



_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Post #1400949
Posted Friday, December 28, 2012 10:21 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Friday, December 12, 2014 8:24 PM
Points: 1,945, Visits: 3,173
{ISO-11179 rules for data element names} Which can be downloaded where?


http://metadata-standards.org/Document-library/Documents-by-number/WG2-N1551-N1600/WG2N1580_WD_11179-5_Ed3.pdf

But you will sorry. Reading standards is like reading the law; it took me two years on ANSI X3H2 to get comfortable with the language. I would start with some of my stairway stuff on the basics:

data:
http://www.sqlservercentral.com/stairway/72899/

database design:
http://www.sqlservercentral.com/articles/Stairway+Series/69801/

That's hilarious. Care to explain why?


I have a better question: why would anyone think that an unpredictable count of physcial access attempts (not even successes!) on one partcular piece of hardware to one particular table in software from one vendor is part of RDBMS and correct data modeling? On a scale from 1 to 10, what color is your favorite letter of the alphabet?

Let's define what characteristics you want in an identifier.

1) An identifier has to be unique. Otherwise, it is not an identifier. IDENTITY by itself only generates values, it does not constrain, limit, or enforce uniqueness. Nor does it constrain the actual values: if an invoice number is supposed to be at least five digits, there is nothing to prevent you from generating values that violate this, unless you add an additional CHECK constraint.

2) An identifier should be created with the entity, or before the entity exists, but not afterward. This is straight OO theory. Without an identifier, you simply cannot put an entity into the database. As an example of an identifier coming into existence before the entity, think about a book that has not been published yet. It can be assigned an ISBN (International Standard Book Number), a title, an author, a price, and everything else while the publisher is waiting to get the manuscript.

But a future release book does not behave like a real book. You cannot put it in a box and ship it. You cannot get a review of the book either -- at least not an honest review . It is not the same kind of thing as a published book.

3) It should be verifiable within itself. That means that when I see a particular kind of identifier, I ought to know if it is syntactically correct. For example, I know that ISBN10: 0-486-60028-9 has the correct number of digits and that the check digit is correct for a proper International Standard Book Number. Later on I can find out that it identifies the Dover Books edition of AN INVESTIGATION OF THE LAWS OF THOUGHT by George Boole.

4) An identifier should have repeatable verification against the reality that you are trying to capture in your data model.

Exactly what verification means can be a bit fuzzy. At one extreme, prison inmates are moved by taking their fingerprints at control points and courts want DNA evidence for convictions. At the other end of the spectrum, retail stores will accept your check on the assumption that you look like your driver's license photograph.

IDENTITY is an exposed PHYSICAL locator. What does that phrase mean? The value is created by looking at the internal state of the hardware at the time a PHYSICAL record containing a row is inserted into storage. Its purpose is to locate the row without any regard to what the data means.

Think about using a pointer or a track/sector number; same thing but different mechanism. But SQL does not have a pointer data type or the mechanisms to handle pointer operators, garbage collection and housekeeping, so 25+ years ago the original Sybase SQL Server exposed an integer that can map back to the contiguous UNIX storage model used under the covers. It made cursors easier for the programmers and the early SQL engines built on file systems.

IDENTITY is not an attribute in the data model and can never be an attribute in the data model because it does not exist in the reality from which you derive your data model. The purpose is to fake a sequential file's positional record number, so I can reference the PHYSICAL storage location. Sure, I lose all the advantages of an abstract data model, SQL set oriented programming, carry extra data, destroy the portability of code and have no data integrity. Who cares? It is easier to write than a real
normalized RDBMS schema.

A programmer with only a few years in a procedural or OO language is all too foften expected to produce a correct and usable database. What is he going to do? The smart ones will get some help and beg for training, knowing they are over their heads and can ruin the company. Most of them simply start programming SQL as if it were their native programming language. They grab at GUIDs, IDENTITY, ROWID and other proprietary
auto-numbering "features" in SQL products to imitate either a record number (sequential file system mindset) or OID (OO mindset) since they don't know anything else.

They write code with cursors to mimic record-at-a-time file handling -- it is easy do a global replace of READ() with FETCH. They write to temp tables to mimic scratch files in a series of procedural steps. They use dynamic SQL and let the user figure out how the system should work on the fly -- they never had a software engineering course and don't know what coupling and cohesion are.

Experienced database designers look for industry standard codes for their keys first. Try to tell the IRS you don't have anybody's SSN at tax time but ''Cindy Lou Who'' was the 42-nd employee put into the Personnel table and you have the IDENTITY value to prove it. Try to sell a car without a VIN -- using IDENTITY for this would be like identifying a vehicle by the current local parking space number (think about it - that is exactly what an IDENTITY value is).

Finally, it is not possible to have a table with an IDENTITY PRIMARY KEY in anything higher than 2NF. The IDENTITY has no facts about it being stored, so everything in the table will have a transitive dependency on the candidate key.

We know that we have to use industry standard codes, either de facto or de jure. We also appreciate the fact that we can exchange data with the rest of the world. We appreciate the fact that someone else will maintain and define these codes. A trusted external source is a good thing to have.

If you don't have an industry standard or natural key and have to design your own codes, it is hard work to do it right. I know that newbie programmers want to start coding first and thinking later. It does not
work that way and all the "wish magic" in the world will not change that fact. I have several chapters in my books on how to design encoding schemes, but that is another topic.

The first practical consideration is that IDENTITY is proprietary and non-portable, so you know that you will have maintenance problems when you change releases or port your system to other SQL products. Newbies actually think they will never port code! Perhaps they only work for companies that are failing and will be gone. Perhaps their code is such crap nobody else wants their application. Otherwise, you will port code; you will share data with some other database; data does not exist in isolation.

But let's look at the logical problems. First try to create a table with two columns and try to make them both IDENTITY. If you cannot declare more than one column to be of a certain data type, then that thing is not a data type at all, by definition. It is a property which belongs to the PHYSICAL table implementation, not the LOGICAL data in the table.

Next, create a table with one column and make it an IDENTITY. Now try to insert, update and delete different numbers from it. If you cannot insert, update and delete rows from a table, then it is not a table by definition.

Finally create a simple table with one IDENTITY and a few other columns. Use a few statements like

INSERT INTO Foobar (a, b, c) VALUES ('a1', 'b1', 'c1');
INSERT INTO Foobar (a, b, c) VALUES ('a2', 'b2', 'c2');
INSERT INTO Foobar (a, b, c) VALUES ('a3', 'b3', 'c3');

To put a few rows into the table and notice that the IDENTITY sequentially numbered them in the PHYSICAL order they were presented. If you delete a row, the gap in the sequence is not filled in and the sequence continues from the highest number that has ever been used in that column in that particular table. This is how we did record numbers in pre-allocated sequential files in the 1950's, by the way. A utility program would then "pack" or "compress" the records that were flagged as deleted or unused to move the empty space to the PHYSICAL end of the PHYSICAL file. IDENTITY leaves the gaps unless you write your own routine to do the compression.

But now use a statement with a query expression in it, like this:

INSERT INTO Foobar (a, b, c)
SELECT x, y, z
FROM Floob;

Since a query result is a table, and a table is a set which has no ordering, what should the IDENTITY numbers be? The entire, whole, completed set is presented to Foobar all at once, not a row at a time.

There are (n!) ways to number (n) rows, so which one did you pick? Why? The answer has been to use whatever the PHYSICAL order of the result set happened to be. That non-relational phrase "PHYSICAL order" again!

But it is actually worse than that. If the same query is executed again, but with new statistics or after an index has been dropped or added, the new execution plan could bring the result set back in a different PHYSICAL order. Indexes and statistics are not part of the logical model.

Can you explain from a logical model why the same rows in the second query get different IDENTITY numbers? In the relational model, they should be treated the same if all the values of all the attributes are identical.

How do you verify that an entity has the right key when you use an IDENTITY? If I use a VIN for a vehicle, I can go to parking lot and read it off the dashboard. If I use a UPC for a candy bar, I can read the bar code on the wrapper. But why is little 'Cindy Lou Who' employee 42? If I turn her upside, will I find that she has 42 tattooed somewhere? If I call an external trusted source, will they know that she is employee 42?

In the Relational Model, you do not invent a key in the storage. You discover a key (and the other attributes) in the real world and model it. If you create your own encoding for a key, then you have to maintain it, provide audit trails and do all the work that an industry standard organization would do for you.

If I lean on a mouse button, I can insert the same data with a new IDENTITY over and over. 'Cindy Lou Who' is now employed two times and none of my reports are right! Now I have to write some procedural code like a trigger or a UNIQUE constraint on her SSN to prevent this, thus making the IDENTITY redundant. But we were assuming that we use only IDENTITY as a key, so we are screwed.

Newbies often design tables without bothering to look for a relational key, so they are so surprised when they do a data warehouse and nobody else has any idea what they are doing in their subsystem.

'Cindy Lou Who' now has two rows in Personnel. When we sign her up for the Dental Plan, we get the row with 42. When we sign her up for the Bowling Team, we get the row with 43. We find our error, and delete the row with 42 because we have a row that was created later and we assume it is more current.

Another common way to get this is to have two procedures, one for inserting a new employee to the Dental Plan and one for inserting a new employee to the Bowling Team. Both procedures create a row in Personnel since they use only IDENTITY as a key.

Well, now we have an orphan row in Personnel. In fact, in such systems, you will find a lot of orphans. I worked for a company that used GUIDs for OIDs substitutes and our software fell apart in about a year of actual use by a client.

Another cute way to destroy data integrity:

BEGIN TRANS
DELETE FROM Foobar
WHERE id = <expr>;
COMMIT;
INSERT INTO Foobar
VALUES (<expr>);
COMMIT;
END;

Logically this should do nothing, but since IDENTITY has gaps, it trashes the data. When one query uses the IDENTITY and another uses the real key, you are like a man with two watches, you are never sure what time it is.

Finally, an appeal to authority, with a quote from Dr. Codd: "..Database users may cause the system to generate or delete a surrogate, but they have no control over its value, nor is its value ever displayed to them ..."(Dr. Codd in ACM TODS, pp 409-410) and Codd, E. (1979), Extending the database relational model to capture more meaning. ACM Transactions on Database Systems, 4(4). pp. 397-434.

This means that a surrogate ought to act like an index; created by the user, managed by the system and NEVER seen by a user. That means never used in queries, DRI or anything else that a user does.

Codd also wrote the following:

"There are three difficulties in employing user-controlled keys as permanent surrogates for entities.

(1) The actual values of user-controlled keys are determined by users and must therefore be subject to change by them (e.g. if two companies merge, the two employee databases might be combined with the result that some or all of the serial numbers might be changed.).

(2) Two relations may have user-controlled keys defined on distinct domains (e.g. one uses social security, while the other uses employee serial numbers) and yet the entities denoted are the same.

(3) It may be necessary to carry information about an entity either before it has been assigned a user-controlled key value or after it has ceased to have one (e.g. and applicant for a job and a retiree).

These difficulties have the important consequence that an equi-join on common key values may not yield the same result as a join on common entities. A solution - proposed in part [4] and more fully in [14] - is to introduce entity domains which contain system-assigned surrogates. Database users may cause the system to generate or delete a surrogate, but they have no control over its value, nor is its value ever displayed to them....." (Codd in ACM TODS, pp 409-410).

References
Codd, E. (1979), Extending the database relational model to capture more
meaning. ACM Transactions on Database Systems, 4(4). pp. 397-434



Books in Celko Series for Morgan-Kaufmann Publishing
Analytics and OLAP in SQL
Data and Databases: Concepts in Practice
Data, Measurements and Standards in SQL
SQL for Smarties
SQL Programming Style
SQL Puzzles and Answers
Thinking in Sets
Trees and Hierarchies in SQL
Post #1400967
Posted Friday, December 28, 2012 10:57 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 3:44 PM
Points: 2,324, Visits: 3,500
Bhuvnesh (12/27/2012)
Also please post exec plan(people would prefer graphical plan ) along with index definition too as index play significant role to pull out the data faster.



Agreed. The indexes on Electionhist will be especially critical to performance. If you've got the "default", no-thought identity-only clustered index, performance will never be that good.


SQL DBA,SQL Server MVP('07, '08, '09)

Carl Sagan said: "There is no such thing as a dumb question." Sagan obviously never watched a congressional hearing!
Post #1400984
Posted Friday, December 28, 2012 12:11 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 3:05 PM
Points: 13,320, Visits: 12,804
Joe I certainly understand your position but I do have a question. You continually refer to Cindy Lou Who as employee #42. In a Joe Celko database what would be used for the primary key in this table?

You can't use SSN. That would be a reasonable choice at first glance but there are two MAJOR flaws with that. First of all, SSN have and will be reused. When people die their SSN gets recycled into the available pool. Secondly, and probably far more important, is that SSN is sensitive information. Anytime you have SSN in your database it should be in one and only one location and it should be encrypted at rest. This pretty much rules out SSN as a valid primary key. What else is there? Name certainly doesn't do it.


_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Moden's splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Post #1401006
Posted Friday, December 28, 2012 1:27 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 3:44 PM
Points: 2,324, Visits: 3,500
Sean Lange (12/28/2012)
Joe I certainly understand your position but I do have a question. You continually refer to Cindy Lou Who as employee #42. In a Joe Celko database what would be used for the primary key in this table?

You can't use SSN. That would be a reasonable choice at first glance but there are two MAJOR flaws with that. First of all, SSN have and will be reused. When people die their SSN gets recycled into the available pool. Secondly, and probably far more important, is that SSN is sensitive information. Anytime you have SSN in your database it should be in one and only one location and it should be encrypted at rest. This pretty much rules out SSN as a valid primary key. What else is there? Name certainly doesn't do it.


Not to mention that some employees may not even have SSNs: foreign representatives, etc..

An identity is clearly applicable to many things, including (but not limited to) employee numbers and order numbers. Obviously you create a unique constraint of some type to guarantee uniqueness.


SQL DBA,SQL Server MVP('07, '08, '09)

Carl Sagan said: "There is no such thing as a dumb question." Sagan obviously never watched a congressional hearing!
Post #1401040
Posted Friday, December 28, 2012 1:31 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Wednesday, January 16, 2013 4:23 PM
Points: 415, Visits: 2,333
CELKO (12/27/2012)

I guess PK means “NOT NULL PRIMARY KEY”, but a good SQL programmer never uses IDENTITY for a key.


That's hilarious. Care to explain why?


I would like to second this evaluation. IDENTITY for a table's primary key is out there as an accepted practice, especially when there's no suitable natural key. Surely there's some good SQL programmers out there doing exactly what CELKO says they do not do.

edit: quote tag
Post #1401041
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse