I have the following table
CREATE TABLE [dbo].[LogFiles_Warehouse](
[id] [int] IDENTITY(1,1) NOT NULL,
[timestamp] [datetime] NOT NULL,
[clientNr] [int] NOT NULL,
[server] [nvarchar](150) COLLATE Latin1_General_CI_AS NOT NULL,
[storeNr] [int] NOT NULL,
[account] [nvarchar](50) COLLATE Latin1_General_CI_AS NOT NULL,
[software] [nvarchar](300) COLLATE Latin1_General_CI_AS NOT NULL,
CONSTRAINT [PK_Astoria_LogFiles_Warehouse] PRIMARY KEY CLUSTERED
(
[id] ASC
)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
And want to avoid having duplicate rows in my table. I thought about creating a UNIQUE index on the complete table, but then SQL Manager Studio tells me that this is not possible because the key would be too large.
Is there another way I could enforce unique rows over all columns, apart from indexes?
Create a UNIQUE index on hashed values:
CREATE TABLE [dbo].[LogFiles_Warehouse]
(
[id] [int] IDENTITY(1,1) NOT NULL,
[timestamp] [datetime] NOT NULL,
[clientNr] [int] NOT NULL,
[server] [nvarchar](150) COLLATE Latin1_General_CI_AS NOT NULL,
[storeNr] [int] NOT NULL,
[account] [nvarchar](50) COLLATE Latin1_General_CI_AS NOT NULL,
[software] [nvarchar](300) COLLATE Latin1_General_CI_AS NOT NULL,
serverHash AS CAST(HASHBYTES('MD4', server) AS BINARY(16)),
accountHash AS CAST(HASHBYTES('MD4', account) AS BINARY(16)),
softwareHash AS CAST(HASHBYTES('MD4', software) AS BINARY(16))
)
CREATE UNIQUE INDEX
UX_LogFilesWarehouse_Server_Account_Software
ON LogFiles_Warehouse (serverHash, accountHash, softwareHash)
Use triggers + a smaller non unique index over the most distinguishing ields to helop aleviate the table s can problem.
This goes down a lot into a bad database design to start with. Fields like Software, Account do not belong into that table to start with (or if account, then not client nr). Your table is only so wisde because you arelady violate database design basics to start with.
Also, to abvoid non unique fields, you have NT to have the Id field in the unique testing otherwise you ont ever have doubles to start with.
Related
I have a huge table for logging. The definition is:
CREATE TABLE [dbo].[TRACELOG]
(
[ID] [int] IDENTITY(1,1) NOT NULL,
[TYPE] [varchar](15) NOT NULL,
[DATEHEURE] [datetime] NOT NULL,
[PROGRAMME] [varchar](25) NOT NULL,
[APPLICATION] [varchar](50) NOT NULL,
[DESCRIPTION] [text] NULL,
[UTILISATEUR] [varchar](10) NOT NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
Indexes are like this:
The table has now about 18 millions or row. When I run a query using ID = 123456, the query is very long.
SELECT *
FROM TRACELOG
WHERE ID = 123456
I'm very surprised... My question is: in a table with IDENTITY, is there an implicit index created on the column in question (not visible in indexes?) or have I to create manually?
NO - having an IDENTITY column does not automatically create an index.
What does create an automatic (and by default clustered) index is the PRIMARY KEY constraint - which is often used on IDENTITY columns.
But not every IDENTITY column has to be the primary key of its table - you have to specify that if you want it that way.
I have created this table, I can't enter data manually because of this error.
USE [Butterfly]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[VM_Vehicles](
[VehicleID] [nvarchar](100) NOT NULL,
[VehicleType] [nvarchar](100) NULL,
[RegistrationNo] [nvarchar](100) NULL,
[PurchaseDate] [date] NULL,
[Make] [nvarchar](100) NULL,
[Model] [nvarchar](100) NULL,
[ChassisNo] [nvarchar](100) NULL,
[EngineNo] [nvarchar](100) NULL,
[EngineCapacity] [nvarchar](100) NULL,
[YearofManufacture] [nvarchar](100) NULL,
[SeatingCapacity] [nvarchar](100) NULL,
[ContactName] [nvarchar](100) NULL,
[Phone] [nvarchar](50) NULL,
[VendorID] [int] NOT NULL,
[Picture] [image] NULL,
[VoucherNo] [int] NOT NULL,
CONSTRAINT [PK_VM_Vehicles1] PRIMARY KEY CLUSTERED
(
[VehicleID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
I have tried using this code to find what's wrong with my database. so far no luck finding error.
IF object_id("tempdb..#VM_Vehicles") is not null
DROP TABLE #VM_Vehicles
CREATE TABLE #VM_Vehicles (vehicleID nvarchar(100), ...);
I already tried changing constraint name and table name. That didn't provide me a answer either.
You are creating a persistent table VM_Vehicles in database Butterfly. However, you are checking a temporary table #VM_Vehicles in database TempDB:
IF object_id("tempdb..#VM_Vehicles") is not null
So you are checking another table from another database and so you have a such error:
There is already an object named ' ' in the database
The correct check statement should look like this:
USE Butterfly
IF OBJECT_ID("VM_Vehicles") IS NOT NULL DROP TABLE VM_Vehicles
CREATE TABLE [dbo].[VM_Vehicles](VehicleID nvarchar(100), ...);
I'm using SQL Server Management Studio 2008 R2 to create a database diagram. I've dropped in the tables that already have foreign key relationships; in addition, all the tables have primary keys. However, when I try to drag and drop from either table onto the other, I get the following error popup:
Primary key or UNIQUE constraint must be defined for table 'Results' before it can participate in a relationship.
Again, both tables have primary keys. The database was imported via Microsoft's SQL Server Migration Assistant for Access tool to preserve relationships and keys. What am I doing wrong?
Update: Here's the table:
CREATE TABLE [dbo].[Results](
[Result_AN] [int] IDENTITY(1,1) NOT NULL,
[Detail_AN] [int] NULL,
[Drug] [nvarchar](10) NULL,
[LDrug] [nvarchar](10) NULL,
[Lab_Result] [nvarchar](10) NULL,
[MRO_Result] [nvarchar](10) NULL,
[Confirm] [nvarchar](6) NULL,
[CutOff] [nvarchar](6) NULL,
[Quant] [nvarchar](10) NULL,
[Screen] [nvarchar](6) NULL,
[Unit] [nvarchar](6) NULL,
[Deleted] [bit] NULL,
[Scrn_Result] [nvarchar](10) NULL,
[SSMA_TimeStamp] [timestamp] NOT NULL,
CONSTRAINT [Results$PrimaryKey] PRIMARY KEY CLUSTERED
(
[Result_AN] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
This question already has answers here:
Adding an identity to an existing column
(19 answers)
Closed 8 years ago.
I have created a SQL Server database table but forgot to set auto increment in the primary key column. How can I set the auto increment to the existing primary key field?
CREATE TABLE [dbo].[STUDENT_INFO]
(
[ROLLNO] [INT] IDENTITY(1, 1) NOT NULL,
[SCHOOLID] [INT] NOT NULL,
[STUDENTID] [INT] NOT NULL,
[NAME] [NVARCHAR](50) NOT NULL,
[AGE] [INT] NOT NULL,
[GENDER] [NVARCHAR](10) NOT NULL,
[ADDRESS] [NVARCHAR](500) NULL,
[CONTACTNO] [NVARCHAR](20) NOT NULL,
[EMAIL] [NVARCHAR](50) NULL,
[ISACTIVE] [BIT] NOT NULL,
[INSTRUMENTID] [INT] NOT NULL,
[GRADEID] [INT] NOT NULL,
[DISCOUNT] [INT] NOT NULL,
[STARTTIME] [TIME](7) NOT NULL,
[DURATION] [TIME](7) NOT NULL,
PRIMARY KEY CLUSTERED ( [STUDENTID] ASC ) WITH (PAD_INDEX = OFF,
STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
)
ON [PRIMARY]
I am working with SQL Server Management Studio 2012.
I was about to say that it can't be done. That you have to drop and recreate the primary key (or, just create the entire table from scratch, move the data over, and drop the old table).
EDIT:
But depending on your version and edition of SQL Server, you may be able to use the object explorer to navigate to the table and access its design properties there. Where you can then set the column to an identity type.
However as someone pointed out, it may actually drop and recreate the table anyway in the background.
Anyway, as the OP already contains an edit to an answer the same as what I suggested at first (replacing the PK with another one, or recreating the table and moving the data there), I suppose there's no need to go further into this.
I have the following database design:
TABLE [Document]
[DocumentId] [int] NOT NULL, --Primary Key
[Status] [bit] NULL,
[Text] [nvarchar](max) NULL,
[FolderPath] [nvarchar](max) NULL
TABLE [Metadata]
[MetadataId] [int] IDENTITY(1,1) NOT NULL, -- Primary Key
[DocumentId] [int] NOT NULL, -- Foreign Key Document.DocumentId (1:1 relationship)
[Title] [nvarchar](250) NOT NULL,
[Author] [nvarchar](250) NOT NULL
TABLE [Page](
[PageId] [int] IDENTITY(1,1) NOT NULL, -- Primary Key
[DocumentId] [int] NOT NULL, -- Foreign Key Document.DocumentId (1:N Relationship)
[Number] [int] NOT NULL,
[ImagePath] [nvarchar](max) NULL,
[PageText] [nvarchar](max) NOT NULL
TABLE [Word](
[WordId] [int] IDENTITY(1,1) NOT NULL, -- Primary Key
[PageId] [int] NOT NULL, -- Foreign Key Page.PageId (1:N Relationship)
[Text] [nvarchar](50) NOT NULL
TABLE [Keyword](
[KeywordId] [int] IDENTITY(1,1) NOT NULL, -- Primary Key
[Word] [nvarchar](50) NOT NULL
TABLE [DocumentKeyword](
[Document_DocumentId] [int] NOT NULL, -- Foreign Key Document.DocumentId (N:N Relationship)
[Keyword_KeywordId] [int] NOT NULL -- Foreign Key Keyword.KeywordId
I'm using Entity Framework Code First to create the database.
Should I be normalizing my database design further? i.e. creating link tables between Document and Page, Document and Metadata, etc.? If so, is there a way to get the Entity Framework to do create the relationship tables for me, so that I don't have to include them in my models? I'm trying to learn to do this the right and most efficient way possible.
Thank you.
Well I can't immediately answer your question, but I have some thoughts that might improve your design:
A document (in real life, at least) can be written by more than one
author. This means, that your 1:1 relationship from Document to
Metadata should be a 1:n relationship (unless you can prove that
there will never be a situation that there's more than one author)
The title of a document is (in my view) more a property of the document than a piece of metadata (also having 1. in mind)
What does this Word table do?
The column Keyword_KeywordId should be called plainly KeywordId if you want to be consistent in your naming. The same applies to
Document_DocumentId.
For the rest it looks pretty normalized