I am working on a current ongoing project where, there are two instances of the database having different schemas for some of the tables and is being used for transfer from one to another.
Database schema is not well defined like,
No Primary key for some of the tables
Primary key as a composite key
Foreign keys in composite primary keys
Foreign key constraint referencing the primary key column of the same table
Composite primary key has been referenced as a foreign key in another table
Having more than 400 tables and will be increased
Application having very less OOPS concept implemented or let's say less objects used at all.
So, looking for some answers if at all, we introduce NHibernate with Repository pattern at this particular time, to faster the development process.
Cheers.
I have successfully introduced it into a project that had tons of custom sql and it worked quite successfully, hardest part was mapping the tables to an object model that was at least partly oksih. But other than that, it was good and it made things go a lot faster and helped with testing and got rid of a lot of SQL query issues.
Related
When creating/inserting a foreign key relationship in Postgres what steps does the backend perform that ensure the referential integrity of my tables?
How does Postgres know where the relevant foreign keys are in the many tables?
All of my searches just say how to implement and examples but not the nuts and bolts of the backend. If I wrote my own checks when inserting data would that be the same thing and as efficient as Postgres?
Postgres documentation is unsatisfying in its description:
"In simplistic database systems this would be implemented (if at all)
by first looking at the cities table to check if a matching record
exists, and then inserting or rejecting the new weather records. This
approach has a number of problems and is very inconvenient, so
PostgreSQL can do this for you."
Edit: Nice book link I'm guessing will answer my question The Internals of PostgreSQL
Clarification: I am not intending to write my own checks or triggers, I understand they will not be as good. The question is to glean details and a better understanding of optimizations.
It is of course recommended to use foreign keys in the DB rather than writing any code in any trigger or backend. Let me explain the reasons:
You don't write any additional codes on backend or on triggers.
If the business logic ever changes, you won't have to make many changes to the code.
If you have to manually write foreign keys yourself, maybe you will have any bugs or you will forget to write checking foreign keys, but foreign keys on DB reliably always provides this check.
During migration, maybe someone will run a bulk insert on the DB from the outside your backend, or if someone (or DB admin) will be deleted data mistily, foreign keys on DB will strictly not allow this.
Should I build the relationships with the database schema or deal with them programmatically?
For Example When I build the database in MSSQL I can to not build the relationships and deal with the relationships programmatically like checking if a key is exist as a primary key in another table and determine upon that to insert the new row to the table or not.
could anyone advise me if it is a good practice or not.
DO make relationships between tables explicit by declaring foreign key constraints.
I do not see any good reason for not doing this. Why are foreign key constraints a good idea?
Foreign key constraints are a simple way to help safeguard data integrity/consistency.
Constraints (not just foreign key ones) can also be seen as a form of "living documentation" (making things explicit and therefore discoverable, without having to guess).
You might still want to validate inserts in code; in that case you can look at foreign key constraints as a "safety net", in case your code fails.
(Regarding the second bullet point above: I have to work with one legacy database which is lacking some foreign key constraints that should by all means have been declared. This means that every time I have to make a change to it, I might inadvertently break an application that makes certain assumptions about the schema that aren't obvious by looking at the schema. Working with this database is very painful and error-prone. If I could change one thing about this database, it would be to add all missing constraints.)
it depends upon your need.
If you are designing OLTP applciation then builing relationship is good but if you designing datawarehouse DWH or datamart then it is advisable not to establish relationship in schema and handle it in code.
Does Index on every Foreign Key makes queries optimized ??
Typically it's considered good practice to place indexes on foreign keys. This is done b/c it helps with join performance when linking the FK table to the table that contains the definition of the key.
This doesn't magically make your entire query optimized, but it will definitely help to improve the join performance between the FK and it's Primary Key counter-part.
It might be a seen as a good practice to add an index on every foreign key, but you should be warned that if you have a large database, the more index you have, the more heavy you system will become. There are always extra maintenance and system resource cost required when adding an index.
I personally would add indexes only on the foreign keys that are used in queries that needs optimization. Be sure to keep your indexes up to date by occasionally running a profiler to monitor your system.
i did a little bit of testing on this, and i didn't find any performance enhancement, but SQLMenace will tell you otherwise. My opinion is to try it and see if it works for you.
I have an issue I am working with an existing SQL Server 2008 database: I need to occasionally change the primary key value for some existing records in a table. Unfortunately, there are about 30 other tables with foreign key references to this table.
What is the most elegant way to change a primary key and related foreign keys?
I am not in a situation where I can change the existing key structure, so this is not an option. Additionally, as the system is expanded, more tables will be related to this table, so maintainability is very important. I am looking for the most elegant and maintainable solution, and any help is greatly appreciated. I so far have thought about using Stored Procedures or Triggers, but I wanted some advice before heading in the wrong direction.
Thanks!
When you say "I am not in a situation where I can change the existing key structure" are you able to add the ON UPDATE CASCADE option to the foreign keys? That is the easiest way to handle this situation — no programming required.
As Larry said, On Update Cascade will work, however, it can cause major problems in a production database and most dbas are not too thrilled with letting you use it. For instance, suppose you have a customer who changes his company name (and that is the PK) and there are two million related records in various tables. On UPDATE Cascade will do all the updates in one transaction which could lock up your major tables for several hours. This is one reason why it is a very bad idea to have a PK that will need to be changed. A trigger would be just as bad and if incorrectly written, it could be much worse.
If you do the changes in a stored proc you can put each part in a separate transaction, so at least you aren't locking everything up. You can also update records in batches so that if you have a million records to update in a table, you can do them in smaller batches which will will run faster and have fewer locks. The best way to do this is to create a new record in the primary table with the new PK and then move the old records to the new one in batches and then delete the old record once all related records are moved. If you do this sort of thing, it is best to have audit tables so you can easily revert the data if there is a problem since you will want to do this in multiple transactions to avoid locking the whole database. Now this is harder to maintain, you have to remember to add to the proc when you add an FK (but you would have to remember to do on UPDATE CASCADE as well). On the other hand if it breaks due to a problem with a new FK, it is an easy fix, you know right what the problems is and can easily put a change to prod relatively quickly.
There are no easy solutions to this problem because the basic problem is poor design. You'll have to look over the pros and cons of all solutions (I would throw out the trigger idea as Cascade Update will perform better and be less subject to bugs) and decide what works best in your case. Remember data integrity and performance are critical to enterprise databases and may be more important than maintainability (heresy, I know).
If you have to update your primary key regularly then something is wrong there. :)
I think the simplest way to do it is add another column and make it the primary key. This would allow you to change the values easily and also related the foreign keys. Besides, I do not understand why you cannot change the existing key structure.
But, as you pointed in the question (and Larry Lustig commented) you cannot change the existing structure. But, I am afraid if it is a column which requires frequent updates then use of triggers could affect the performance adversely. And, you also say that as the system expands, more tables will be related to this table so maintainability is very important. But, a quick fix now will only worsen the problem.
I want to change the primary key of an entity in database, so that all the relevant foreign key constraints are updated as well./We are using NHibenate as our ORM.
Is it possible to do it?
Thanks.
P.S.
I know the practice of changing the primary key is highly discouraged. My problem is that my primary key is backed by a natural Id of the entity, which may sometimes change. We could, theoretically, utilize a unique primary key, unrelated to the natural key of the entity, but this complicates things too much in other places, so this is not an option.
I'm not clear on your question.... nHibernate is just a mapping of your database. It seems that to do what you are suggesting you just need to change your database to whatever you need it to be, redo your mapping files, then modify any queries you have to match the new schema...
No, it is not possible. NHibernate will complain if you try to do it.
The only way to do it "from" NHibernate is using CreateSQLQuery.