Having briefly studied databases in college, I haven't worked with them since and have drawn a bit of a blank, so I was wondering if someone could help me out. I have a database called Convert, which holds the following tables:
**File**
ID int PK
ISBN nvarchar(MAX)
UserName nvarchar(50)
CoverID
PDFID
**PDF**
PDFID int PK
FileContent image
MimeType nvarchar
FileName nvarchar
**Cover**
CoverID int PK
FileContent image
MimeType nvarchar
FileName nvarchar
I've just drawn a blank on two things really.
Relationships. I think if I a sql query such as below I will create foreign keys:
Alter TABLE Cover ADD FOREIGN KEY (CoverID) REFERENCES File (CoverID)
What I need to do is create one to one relationships --> One File will have one Cover, and one PDF.
The second is thing I'm having difficulty getting my head around again is the insert statements. Any advice on how I should handle those would be appreciated?
I'm using SQL Server 2008 Also.
If you need to retain your current table structure (and #none is right - if it's really a one-to-one relationship there's no benefit to having three tables) you can get what you want by doing the following:
Define two foreign key constraints on File, one on File.PDFID referencing PDF.PDFID and the other on File.CoverID referencing Cover.CoverID.
Define two UNIQUE constraints on the File table, one on File.PDFID and the other on File.CoverID.
Share and enjoy.
if you want to ensure that a relation will have one to one relationship, then make one big table.
one table where you have
create table
ID int PK
ISBN nvarchar(MAX)
UserName nvarchar(50)
PDFFileContent image
PDFFileName nvarchar
CoverFileContent image
CoverFileName nvarchar
what you might ment in your original design is to make one table that could contain all 3 types and each row is different by having different value at "mime type" which is also possible, if hold keys that relet the table to itself.
such as
create table
ID int pk
ISBN nvarchar(max)
userName nvarchar(50)
pdfID int fk table2 id
coverID int fk table 2 id
create table2
id pk int
fileContent image
fileName nvarchar
mimetype (something)
A true one-to-one relationship would look like:
which is essentially a vertically partitioned table. In this case, you may also consider simply putting all columns in one table.
Related
I've created a new table and made column id the primary key and defined it as uniqueidentifier.
Is there a way during the tables design in SQL Server Management Studio to assign a rule that all new rows auto generate a new uniqueidentifier in the id column?
At the moment to make my form (made on Retool) write to the table I need to type out a random set of characters, essentially self creating my own uniqueidentifier which obviously isn't correct.
Avoid the designers, they've been a complete and utter mess for 17 years. Do this in a query window:
USE tempdb;
GO
CREATE TABLE dbo.what
(
id uniqueidentifier NOT NULL
CONSTRAINT DF_what_id DEFAULT(NEWSEQUENTIALID()),
-- or NEWID() if you like page splits
name nvarchar(128),
CONSTRAINT PK_what PRIMARY KEY (id)
);
INSERT dbo.what(name) VALUES(N'hi'),(N'there');
SELECT id, name FROM dbo.what;
Output (yours will have different values for id):
id
name
84c37c76-8c0e-ed11-ba5d-00163ef319ff
hi
85c37c76-8c0e-ed11-ba5d-00163ef319ff
there
I created a table for Boat that contains the following columns: BName, Type, Price, OName.
However, the Type column should be one of the following: Sailboat, Houseboat, or Deckboat.
How can I reflect this on the create table statement. I've searched about it and I came up with this statement which I'm not sure if it's right or not:
CREATE TABLE Boat
(
BName varchar(255),
BType int,
Price double,
OName varchar(255),
PRIMARY KEY (BName),
FOREIGN KEY (BType) REFERENCES BoType(ID)
);
CREATE TABLE BoType
(
ID int PRIMARY KEY,
Type varchar(255)
)
Is this the best way to do it?
You can try something like this:
mycol VARCHAR(10) NOT NULL CHECK (mycol IN('moe', 'curley', 'larry'))
Here are more details on MSSQL "Check Constraints":
http://technet.microsoft.com/en-us/library/ms188258%28v=sql.105%29.aspx
That's the best way to do it just make sure that you populate the BoType table with the desired reference values (i.e. Sailboat, Houseboat, Deckboat). Because if you use constraint then you have the user of the database who have no knowledge in SQL or have no access rights in your DB, at your mercy or they become too dependent on you. However, if you set it as a separate table then the user of your system/database even without knowledge about SQL could add or change values via your front-end program (e.g. ASP, PHP). In other words you design is more flexible and scalable not to mention less maintenance in your part.
I have 3 tables, Chapters, SubChapters, and Divisions . Each of these tables have additional records that I would like to store in a table called 'Sections'. They are all 1:many relationships.
My question is what would be the best way to establish the cross reference here? This is what I currently have:
Chapter table:
chapterID int
partID int
chapterNumber varchar
chapterName varchar
SubChapter table:
subChapterID int
chapterID int
subChapterNumber varchar
subChapterName varchar
Division Table:
divisionID int
subChapterID int
divisionNumber varchar
divisionName varchar
Section Table:
sectionID int
parentID int
parentType int (1 = chapter; 2 = subchapter; 3 = division)
sectionNumber varchar
sectionName varchar
The issue I'm running into here are FK restraints. Should I just do away with the foreign keys? What could I do to improve efficiency if I did or would that even be a concern?
For those wondering, my requirements are to have certain aspects of State and Federal administrative code accessible in a database to populate drop-down menus on the intranet webpages.
Personally, I would create a section table for each parent type and then your foreign keys would work properly. I would then create a view to join up all the joins to alleviate the repetitive nature of joining those six tables.
I can certainly appreciate the design you have now, but having the FKs make it nice in preventing orphaned data. Another alternative is to add delete triggers to Chapters, SubChapters, and Divisions to escape the deletion if there is a corresponding Sections record.
More of a question concerning the database model for a specific problem. The problem is as follows:
I have a number of objects that make up the rows in a fixed table, they are all distinct (of course). One would like to create sets that contain a variable amount of these stored objects. These sets would be user-defined, therefore no hard-coding. Each set will be characterized by a number.
My question is: what advice can you experienced SQL programmers give me to implement such a feature. My most direct approach would be to create a table for each such set using table-variables or temporary tables. Finally, an already present table that contains the names of the sets (as a way to let the user know what sets are currently present in the database).
If not efficient, what direction would I be looking in to solve this?
Thanks.
Table variables and temporary tables are short lived, narrow of scope and probably not what you want to use for this. One table for each Set is also not a solution I would choose.
By the sound of it you need three tables. One for Objects, one for Sets and one for the relationship between Objects and Sets.
Something like this (using SQL Server syntax to describe the tables).
create table [Object]
(
ObjectID int identity primary key,
Name varchar(50)
-- more columns here necessary for your object.
)
go
create table [Set]
(
SetID int identity primary key,
Name varchar(50)
)
go
create table [SetObject]
(
SetID int references [Object](ObjectID),
ObjectID int references [Set](SetID),
primary key (SetID, ObjectID)
)
Here is the m:m relation as a pretty picture:
I'm trying to figure out the best way to move/merge a couple tables of worth of data from multiple databases into one.
I have a schema similar to the following:
CREATE TABLE Products(
ProductID int IDENTITY(1,1) NOT NULL,
Name varchar(250) NOT NULL,
Description varchar(1000) NOT NULL,
ImageID int NULL
)
CREATE TABLE Images (
ImageID int IDENTITY(1,1) NOT NULL,
ImageData image NOT NULL
)
With a foreign-key of the Products' ImageID to the Images' ImageID.
So what's the best way to move the data contained within these table from multiple source databases into one destination database with the same schema. My primary issue is maintaining the links between the products and their respective images.
In SQL Server, you can enable identity inserts:
SET IDENTITY_INSERT NewTable ON
<insert queries here>
SET IDENTITY_INSERT NewTable OFF
While idenitity insert is enabled, you can insert a value in the identity column like any other column. This allows you to just copy the tables, for example from a linked server:
insert into newdb.dbo.NewTable
select *
from oldserver.olddb.dbo.OldTable
I preposition the data in staging tables (Adding a newid column to each). I add a column temporarily to the table I'm merging to that is Oldid. I insert the data to the parent table putting the currect oldid inthe oldid column. I use the oldid column to join to the staging table to populate the newid column in the staging table. Now I have the New FK ids for the child tables and ccan insert using them. If you have SQL server 2008, you can use the OUTPUT clause to return the old and newids to a temp table and then use from there rather than dding the column. I prefer, to have the change explicitly stored ina staging table though to troubleshoot issues in the conversion. At the end nullout the values inteh oldid column if you are then going to add records from a third database or drop it if you are done. Leave the staging tables in place for about a month, to make research into any questions easier.
In this case you could move the images and then move the products. This would ensure that any image a product has a reference to will already be in place.