I need help as a new key manager if someone can explain the key creation life cycle.
Workflow to view the relationships between all keys, if available
Related
In dimension Project, there is business logic that Project Number and Project Name can change over time.
Unfortunately, I cannot get any durable key directly from the source system. Is there a way how to deal with this situation? How to generate Project ID column - in this example is acting as Durable key?
See desired dimension structure.
Project ID - durable key not from source system, I need to generate it.
In a passive replication based distributed system, if the primary server fails, one of the backups is promoted as primary. However, suppose that the original primary server recovers, then how do we switch back the primary server to it from the current backup?
I was wondering
if the failed primary server recovers, it must be incorporated into the system as a secondary and updated to reflect the most accurate information at the given point of time. To restore it as the primary server, it can be promoted as the primary in case the current primary (which was originally a backup) fails, otherwise, if required the current primary can be blocked for a while, the original primary promoted as primary again and the blocked reintroduced as backup.
I could not find an answer to this question elsewhere and this is what I feel. Please suggest any better alternatives.
It depends on what system you're looking at. Usually there's no immediate need to replace the backup when the original primary server recovers; if there is, you'd need to synchronize the two and promote the original primary.
Distributed synchronization (or consensus) is a hard problem. There's a lot of literature out there and I recommend that you read up. An example of a passively replicated system (with Leaders/Followers/Candidates) is Raft, which you could start with. A good online visualization can be found here, and the paper is here.
ZAB and Paxos are worth a read as well!
I have a data driven ASP application. And like most data driven applications, i have a Users table and a CreatedBy field in most of the tables.
I am trying to create a DeleteUserFunction in my application. Before deleting any user i must check each and every table to see if that user has created any records.
Building relationships between the users table and the rest of database tables can make the DeleteUserFunction easier to validate.
Therefore, I am trying to figure whether a users table must be explicitly linked to other tables (via foreign key constaints) or must it be handle in application business logic.
First, your functional requirements need to be clarified. What should happen if a user gets deleted?
1 User may not get deleted if records linked to her are present.
2 User may be deleted, and
2.1 all records linked to her stay present, without link to that user,
2.2 all records linked to her must be deleted as well.
A foreign key constraint can support 1 and 2.2, but not 2.1, because it won't change the user foreign key in the referring record.
However, using a foreign key constraint as the only way to enforce this might lead to strange software structure and user experience. In all cases, the violation of the constraint will be detected by the database, and will, by default lead to some exception in the data access module. But probably, you don't want your application to crash with an exception, but rather tell your user that this function is not available (in case 1) or trigger some application function (in cases 2.1, 2.2). This would mean passing the exception around in the software until the right layer to handle the case is reached.
Therefore, I'd recommend to perform the necessary checks to find out whether the deletion is legal and to trigger the logical consequences as part of the application logic. The foreign key constraint may still be useful as a way to detect application error during tests.
I have been wondering about the uniqueness of the GUID across the sql servers.
I have one central Database server and 100's of client databases (both SQL Servers). I have a merge replication (bi-directional) setup to sync the data between client and master servers. The sync process will happen 2-3 times a day.
For each of the tables to be synced I am using GUID as PrimaryKey and each table locally gets new records added and new GUIDs are generated locally.
When GUIDs are getting created at each client machine as well as at master DB server, how it will make sure it generates the unique GUID across all Client & Master DBs?
How it will keep track of GUID generated at other client/server DB, so that it will not repeat that GUID?
GUIDs are unique (for your purposes)
There are endless debates on the internet - I like this one
I think GUID's are not really necessarily unique. Their uniqueness comes from the fact that it's extremely unlikely to generate the same GUID randomly but that's all.
But for your purpose, that should be ok - they should be unique on a distributed system with extremely high probability.
You will have to do more research, but I think GUID is based upon MAC address and timestamp, if I remember right.
http://www.sqlteam.com/article/uniqueidentifier-vs-identity
I know some MCM's who have come across a unique key violation on a GUID.
How can this happen? Well, in the Virtual World, you have virtual adapters.
If you copy one virtual machine from one host to another, you can have the same adapter, MAC address?
Now if both images are running at the same time, it is possible to get no unique GUIDs.
However, the condition is rare. You can always add another field to the key to make it unique.
There is a whole debate on whether or not to use a GUID as a clustered PK. Remember, any other index will take a copy of the PK in the leaf (nodes). This is 16 bytes for every record x number of indexes.
I hope this helps.
John
You don't need to do anything special to ensure a GUID/Uniqueidentifier is globally unique. That basic guarantee is the motivating requirement for the GUID.
I want to build a WCF data service which should be used for CRUD operations on a database backend. In order to identify the related record of the object in the database I have to know it's primary key. I use surrogate keys in my database schema.
Is it a good practice to pass the surrogate keys to the caller, so that it is possible to identify the records in the database in subsequent calls? (Caller retrieves object, caller modifies object, caller calls WCF update method) I know that surrogate keys should normally not be used outside the database. If that is not a good idea, what other options do I have?
Any advice is greatly apreciated.
Yes, your solution is totally adequate. It's the simplest way to map CLR objects to persistent entities. Moreover, your services' consumers may find this unqiue identifier useful when programming UI, for logging purposes etc.
I'd go this way without hesitation.
I think this all depends on what type of data you are talking about. If you are talking about pure resource driven data, there are no issues with exposing surrogate keys. However, if this is business data you should only expose business keys. It allows disjoint systems to talk in a generic way.