Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
DB Engine
SQL ServerMSDESQL Server CE
Services
Analysis (Data Mining)Analysis (OLAP)DTSIntegration ServicesNotification ServicesReporting Services
Programming
CLRConnectivitySQLXML
Other Technologies
ClusteringEnglish QueryFull-Text SearchReplicationService Broker
General
Data WarehousingPerformanceSecuritySetupSQL Server ToolsOther SQL Server Topics
DirectoryUser Groups
Related Topics
MS AccessOther DB ProductsMS Server Products.NET DevelopmentVB DevelopmentJava DevelopmentMore Topics ...

SQL Server Forum / Programming / SQL / August 2008

Tip: Looking for answers? Try searching our database.

Adding multiple rows taken form another table

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Mike - 30 Aug 2008 22:36 GMT
CREATE TABLE [dbo].[Fixtures](
[FixtureID] [int] IDENTITY(1,1) NOT NULL,
[KickOff] [datetime] NOT NULL,
[HomeTeamID] [int] NOT NULL,
[AwayTeamID] [int] NOT NULL,
[HomeTeamScore] [smallint] NULL,
[AwayTeamScore] [smallint] NULL
) ON [PRIMARY]

CREATE TABLE [dbo].[Predictions](
[PredictionID] [int] IDENTITY(1,1) NOT NULL,
[UserID] [int] NOT NULL,
[FixtureID] [int] NOT NULL,
[HomeTeamGoals] [smallint] NOT NULL CONSTRAINT
[DF_Predictions_HomeTeamGoals]  DEFAULT ((0)),
[AwayTeamGoals] [smallint] NOT NULL CONSTRAINT
[DF_Predictions_AwayTeamGoals]  DEFAULT ((0)),
[Points] [int] NULL,
[Submitted] [bit] NOT NULL CONSTRAINT [DF_Predictions_Submitted]  DEFAULT
((0))
) ON [PRIMARY]

When I add a new user, I want to be able to add the FixtureID and the new
UserID to the Predictions table for each existing Fixture.  So far, I've got
the following (which doesn't work):

CREATE PROCEDURE [dbo].[AddUser]
@UserName nvarchar(50),
@Password nvarchar(10),
@EmailAddress nvarchar(130)
AS
BEGIN
DECLARE @ID int
SET NOCOUNT ON;

INSERT INTO Users (UserName, Password, EmailAddress)
VALUES
(@UserName, @Password, @EmailAddress)
SET @ID = SCOPE_IDENTITY()
INSERT INTO Predictions (UserID, FixtureID) SELECT (SELECT USERID From
Users WHERE UserID = @ID), (SELECT FixtureID FROM Fixtures)
Return @ID
END

The subquery returns more than one value, which I'm told isn't allowed.  In
client-side code, I could select all the FixtureIDs and just interate
through them, inserting as I go, but I feel this is inefficient.  Or is it
my only real choice?

Thanks
Aaron Bertrand [SQL Server MVP] - 30 Aug 2008 22:46 GMT
> When I add a new user, I want to be able to add the FixtureID and the new
> UserID to the Predictions table for each existing Fixture.  So far, I've got
> the following (which doesn't work):

If you're going to store the entire set against every user you create, why
bother?  Can't you just perform a join at query time and not store the
relationships at all?  Or, only store the actual relationships when
something changes and you REMOVE one of them?  If you're assuming the
relationship between UserID and every single Fixture is there, then I see no
point in storing it.  But I don't know enough about your application to
understand why you would want to do it, so I'll just leave that there.

>  INSERT INTO Predictions (UserID, FixtureID) SELECT (SELECT USERID From
> Users WHERE UserID = @ID), (SELECT FixtureID FROM Fixtures)

Well, I'm not sure where you got your syntax.  How about:

INSERT INTO Predictions(UserID, FixtureID) SELECT @ID, FixtureID FROM
Fixtures;

?
Mike - 30 Aug 2008 23:04 GMT
>> When I add a new user, I want to be able to add the FixtureID and the new
>> UserID to the Predictions table for each existing Fixture.  So far, I've
[quoted text clipped - 19 lines]
>
> ?

Thanks Aaron - that's exactly what I wanted.  To add to the picture, each
user will predict the outcome of all matches.  Their predicted scores for
the home and the away team will be stored in the Predictions table.  If they
fail to submit a prediction in time, or they join after some fixtures have
been played, their prediction will default to 0 - 0.  Either way, there
needs to be a prediction for each user for each match.  Once a match
(fixture) has been played, the actual score is entered into the Fixtures
table, and each user will be awarded points for their prediction based on
how close their prediction is to the actual score.  As far as I see it, I
need some way to establish which prediction belongs to which user, and which
fixture it relates to.  Does what I am currently doing make sense now?  Or
is there a better way to approach this?

Thanks

Mike
Aaron Bertrand [SQL Server MVP] - 31 Aug 2008 00:01 GMT
> fail to submit a prediction in time, or they join after some fixtures have
> been played, their prediction will default to 0 - 0.  Either way, there
> needs to be a prediction for each user for each match.

Even if they didn't enter one?  Why can't you just say, if not exists then
it is 0-0?  There are ways to make a query LOOK like there are rows when
there aren't.  Storing rows for no reason is just wasteful IMHO.

A
Erland Sommarskog - 31 Aug 2008 10:56 GMT
>> fail to submit a prediction in time, or they join after some fixtures
>> have been played, their prediction will default to 0 - 0.  Either way,
[quoted text clipped - 3 lines]
> it is 0-0?  There are ways to make a query LOOK like there are rows when
> there aren't.  Storing rows for no reason is just wasteful IMHO.

Dunno... I don't know the full plot of Mike's application, but sometimes
it make sense to store extra data. Typically, you only store in one place,
but you query in many, why it can help to make querying easier. I make
such designs from time to time.

But that does not always mean that it is the right thing. It's a trade-off
between updating complexity and querying complexity.

Signature

Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

Mike - 31 Aug 2008 20:45 GMT
>>> fail to submit a prediction in time, or they join after some fixtures
>>> have been played, their prediction will default to 0 - 0.  Either way,
[quoted text clipped - 12 lines]
> But that does not always mean that it is the right thing. It's a trade-off
> between updating complexity and querying complexity.

One of the reasons why every user has a prediction for every match is
because each prediction will score points for the user based on how accurate
it was in relation to the actual match score.  That score needs to be stored
against the prediction.

I suppose in theory, it's possible to calculate virtual points where the
user hasn't made a prediction, but I'd have to do that every time I wanted
to retrieve points for display.  Simply SUMMING existing stored values seems
more efficient to me, although I'm happy to be told otherwise if that's the
case.

Mike
Erland Sommarskog - 31 Aug 2008 23:44 GMT
> One of the reasons why every user has a prediction for every match is
> because each prediction will score points for the user based on how
[quoted text clipped - 6 lines]
> values seems more efficient to me, although I'm happy to be told
> otherwise if that's the case.

One point with storing the default prediction with the user, is that if
you change the default prediction, that should probably not have a
retroactive effect.

Signature

Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.