I needed to set change tracking in sql server 2008 table to true but it gave an error that the table has to have a primary key
Is there a way to enable change tracking without setting a primary key in my table
Is it a good programming practice not to set primary keys? I am creating a system but i don't want to set them on SQL tables
The Table must have primary key in order to enable Change tracking
Having primary keys on a table infarct is a good programming practice.
You can enable Change Tracking on a table which has Primary key.
It is must. Because Change Tracking works based on Primary key in a table.
You can find some more additional information from my Article
http://www.codeproject.com/Articles/537649/SQL-Server-Change-Tracking-CT#_comments
Related
Just starting to learn basics of SQL. In some versions of SQL (Oracle, SQL server etc.) there are enable/disable constraints keywords. What is the difference between these and add/drop constraints keywords? Why do we need it?
Constraint validation has a performance penalty when performing a DML operation. It's common to disable a constraint before a bulk insert/import of data (especially if you know that data is "OK"), and then enable it after the bulk operation is done.
I use disabled constraints in a special situation. I have an application with many tables (around 1000). The records in these table have "natural keys", i.e. identifiers and relations which are given by external source. Some tables use even different natural keys as foreign key references to different tables.
But I like to use common surrogate keys as primary key and for foreign references.
Here is one example (not 100% sure about correct syntax):
CREATE TABLE T_BTS (
OBJ_ID number constraint BTS_PK (OBJ_ID) PRIMARY KEY,
BTS_ID VARCHAR2(20) CONSTRAINT BTS_UK (BTS_ID) UNIQUE,
some more columns);
CREATE TABLE T_CELL (
OBJ_ID number constraint BTS_PK (OBJ_ID) PRIMARY KEY,
OBJ_ID_PARENT number,
BTS_ID VARCHAR2(20),
CELL_ID VARCHAR2(20) CONSTRAINT CELL_UK (BTS_ID, CELL_ID) UNIQUE,
some more columns);
ALTER TABLE T_CELL ADD CONSTRAINT CELL_PARENT_FK
FOREIGN KEY (OBJ_ID_PARENT)
REFERENCES T_BTS (OBJ_ID);
ALTER TABLE T_CELL ADD CONSTRAINT CELL_PARENT
FOREIGN KEY (BTS_ID)
REFERENCES T_BTS (BTS_ID) DISABLE;
In all my tables the primary key column is always OBJ_ID and the key to parent table is always OBJ_ID_PARENT, not matter how the natural key is defined. This makes me easier to have common PL/SQL procedures and compose dynamic SQL Statements.
One example: In order to set OBJ_ID_PARENT after insert, following update would be needed
UPDATE T_CELL cell SET OBJ_ID_PARENT =
(SELECT OBJ_ID
FROM T_BTS bts
WHERE cell.BTS_ID = bts.BTS_ID)
I am too lazy to write 1000+ such individual statements. By using views USER_CONSTRAINTS and USER_CONS_COLUMNS I am able to link the natural keys and the surrogate keys and I can execute these updates via dynamic SQL.
All my keys and references are purely defined by constraints. I don't need to maintain any extra table where I track relations or column names. The only limitation in my application design is, I have to utilize a certain naming convention for the constraints. But the countervalue for this is almost no maintenance is required to keep the data consistent and have good performance.
In order to use all above, some constrains needs to be disabled - even permanently.
I [almost] never disable constraints during the normal operation of the application. The point of the constraints is to preserve data quality.
Now, during maintenance, I can disable them temporarily while adding or removing massive amounts of data. Once they data is loaded I make sure they are enabled again before restarting the application.
I am analysing the database tables and design, I have noticed that there is a table with a column interviewID which is a primary key to the table, it is also a foreign key, the relation says it is a foreign key to itself, how is this even possible. primary key says each value should be unique and not null but foreign key says it has to be one of the existing values? Something wrong with the design? or is there some logic behind this?
When you create a new foreign key in SQL Server Management Studio all controls are set to crazy defaults: a self-referential foreign key on the first column of the table (usually the primary key column). I think somebody did this and just hit save.
It has no purpose whatsoever. Delete it.
In SQL Server 2012, I have a User table to store application users. I also have an Organization table which has a LastModifiedBy field in which I would like to store the UserID of the last person to modify the values within the table via an ASPX page. Should I create a foreign key relationship between the LastModifiedBy field and the UserID field within the Users table?
I would also like to add a LastModifiedBy field to the Users table itself. Should/can I create a self referencing foreign key constraint on this table? If this is possible, is it a horrible idea?
Any perspectives on pros and cons of creating these foreign key constraints would be greatly appreciated.
What you are describing is what foreign keys are made for. These foreign keys are at the very core of relational databases. Even if they might give a slight performance impact when inserting new rows, because it has to check if the referenced key exists, it should not be avoided.
I have tried 2 different online sql table editors,
Universal Table Editor &
Table Smart Editor
When viewing the database using the tools above, if there is a primary key field defined in my tables, it is uneditable. At the beggining I was thinking that it was related to table editor, however 2 different editors resulted the same problem, so I am thinking it is related to sql server.
I am currently using SQL Server 2005.
Here are the images for my editors and my database properties:
Normally, an error message will accompany a failed attempt to modify a database value. What was the message?
This sounds like the primary key is set up as an auto-numbered identity. In this case, the value is determined by the database automatically when each row is created. And you cannot edit this value.
The editors you're using seem to have been built with certain assumptions - that primary key values never change, and furthermore that they're always system generated.
Neither assumption is generally true. Whilst it's often described as desirable that primary key values never change, a good tool should not assume this to be true. Nor should it assume that primary key values will always be auto-generated.
There are some mitigating features built into SQL to deal with primary keys that do change - notably, the CASCADE features of FOREIGN KEY constraints.
Is there any way to define relationship among tables and give foreign keys among them while using sqlite in Objective c
you can use foreign keys in sqlite the same way as in other sql-datebase systems but be aware that foreign key constraints in sqlite are not checked/enforced!
SQLite isn't a "real" relationnal-database, you can have fields that link to other tables primary key, but you have to control all from your code.
Same for deleting, no CASCADE or other integrity controls.
You can easily create a foreign key by adding a FOREIGN KEY statement to the SQL CREATE command.
For example when having a person and address entity:
Create the person table:
CREATE TABLE IF NOT EXISTS PERSON (ID INTEGER PRIMARY KEY AUTOINCREMENT, FIRSTNAME TEXT, LASTNAME TEXT)
Create the address table:
CREATE TABLE IF NOT EXISTS ADDRESS (ID INTEGER PRIMARY KEY AUTOINCREMENT, STREETNAME TEXT, STREETNUMBER INT, PERSONID INT, FOREIGN KEY(PERSONID) REFERENCES PERSON(ID))
This will mark the PERSONID column of the ADDRESS table as a foreign key pointing to the ID column of the PERSON table.
You can also find a full tutorial at:
http://www.apptite.be/tutorial_ios_sqlite.php
you can define foreign key relations in sqlite like in any other sql database system but to actually enforce them you need additional triggers. these can be compiled automatically from the database scheme with a tool shipped with the official sqlite distribution.
the big advantage of this solution is that it is programming language agnostic. once setup you don't have to care about the triggers in your source code anymore. see http://www.sqlite.org/omitted.html for more information.
If you use the Cocoa CoreData framework, and define a managed object model, using SQLite as the persistent store - you can specify the relations between your model, and specify deletion rules ( such as cascade or deny ) and these will be performed and validated as you make changes to your entities from Objective-C, and committed back to the database when you save.
The relationships and rules are very similar to database foreign key rules, but are performed by the CoreData framework inside the objective-C runtime. The SQLite database is just used as a persistence store for your managed object graph.
Here is the CoreData programming guide at the Apple Developer Site:
NB This framework is Cocoa-specific, and your question doesn't explicitly mention using Cocoa, just Objective-C
You can set one flag in SQLite for foreign key relationship.
Step 1: Go to tool menu in SQLiteManager.
Step 2: Open On-Connect SQL tab.
Step 3: Set "PRAGMA foreign_keys=ON;" and save it.
You can use database as normal PK and FK relationship.
Thanks.