Sunday, March 11, 2012
Database Diff?
1 from production and 1 from development.
None of the developers kept a changelog so i need to know what has changed (or what is different between the 2).
Any Ideas on how to do this?A quick method is to compare selects from sysobjects, syscolumns, and sysindexes.
blindman|||Then give the output of those queries to the developers so they can sift through them. Only proper, I would imagine.|||A quick, first run is to compare the date modified of the objects. Of course this does not compare contents. I've done it this way and it wasn't as bad as it sounds. Good luck.|||...and a quick way to identify modified procedure code is to compare checksum(syscolumns.text) between the two databases.
blindman|||if this is recurring task and if your department has a few dollars to spare (as we all have ...), you can use software for this, e.g. http://www.red-gate.com/sql/summary.htm|||SQLDiff by ApexSQL is a good tool too. There are some free database compare scripts at http://www.sqlservercentral.com/. Just look in their script section on the site.|||Another way - create db scripts (use DMO) and compare by FC.exe (included in W2000).
Wednesday, March 7, 2012
Database design question...
experienced developers might be able to answer...
Early on in the development of the DB for a project we are working on, the
decision was made to use physical deletion of records from the DB rather
than logical deletion. This seemed to be working just fine until now.
We have added entity history functionality to our application (per the
requirements) in which we use history tables in the DB to maintain change
histories of many entities. These tables include foreign keys that
reference the records in the original tables for which they are maintaining
a history.
Now, when attempting to physically delete an entity for which history
records exist, we are obviously bumping up against referential integrity
issues.
Our options seem to be:
1. Stop enforcing referential integrity between history records and the
records they reference.
2. Switch from physical deletion to logical deletion of records.
I was wondering if anyone might have some advice/insight on which of these
two options would be better. We tend to think that option 2 is the better
way to go, but we are not yet sure of the implications of trying to make a
change like this at this point in the development process.
Any input would be highly apreciated!!!!
Thanks."craig" <e@.mail.com> wrote in message
news:8TM9f.163662$lI5.141621@.tornado.ohiordc.rr.co m...
>I have a question about database design that I think some of the more
>experienced developers might be able to answer...
> Early on in the development of the DB for a project we are working on, the
> decision was made to use physical deletion of records from the DB rather
> than logical deletion. This seemed to be working just fine until now.
> We have added entity history functionality to our application (per the
> requirements) in which we use history tables in the DB to maintain change
> histories of many entities. These tables include foreign keys that
> reference the records in the original tables for which they are
> maintaining a history.
> Now, when attempting to physically delete an entity for which history
> records exist, we are obviously bumping up against referential integrity
> issues.
> Our options seem to be:
> 1. Stop enforcing referential integrity between history records and the
> records they reference.
> 2. Switch from physical deletion to logical deletion of records.
> I was wondering if anyone might have some advice/insight on which of these
> two options would be better. We tend to think that option 2 is the better
> way to go, but we are not yet sure of the implications of trying to make a
> change like this at this point in the development process.
> Any input would be highly apreciated!!!!
> Thanks.
This has been answer in microsoft.public.sqlserver.programming.
Please do not multi-post.
--
David Portas
SQL Server MVP
--|||"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:v7udnQrqD7ZPdPreRVnyjA@.giganews.com...
> "craig" <e@.mail.com> wrote in message
> news:8TM9f.163662$lI5.141621@.tornado.ohiordc.rr.co m...
>>I have a question about database design that I think some of the more
>>experienced developers might be able to answer...
>>
>> Early on in the development of the DB for a project we are working on,
>> the decision was made to use physical deletion of records from the DB
>> rather than logical deletion. This seemed to be working just fine until
>> now.
>>
>> We have added entity history functionality to our application (per the
>> requirements) in which we use history tables in the DB to maintain change
>> histories of many entities. These tables include foreign keys that
>> reference the records in the original tables for which they are
>> maintaining a history.
>>
>> Now, when attempting to physically delete an entity for which history
>> records exist, we are obviously bumping up against referential integrity
>> issues.
>>
>> Our options seem to be:
>>
>> 1. Stop enforcing referential integrity between history records and the
>> records they reference.
>> 2. Switch from physical deletion to logical deletion of records.
>>
>> I was wondering if anyone might have some advice/insight on which of
>> these two options would be better. We tend to think that option 2 is the
>> better way to go, but we are not yet sure of the implications of trying
>> to make a change like this at this point in the development process.
>>
>> Any input would be highly apreciated!!!!
>>
>> Thanks.
>>
> This has been answer in microsoft.public.sqlserver.programming.
> Please do not multi-post.
> --
> David Portas
> SQL Server MVP
Potentially different audiences on two different servers with different
perspectives.|||So CROSS-POST if you must. Do NOT multi-post.
Multi-posting is extremely inconsiderate to those who help you as well
as likely to be ultimately less productive for you. That's because
multi-posting divides, weakens and renders redundant the efforts of
others and makes it more likely they will kill or ignore your posts in
future. If you don't know how to cross-post then read your manual.
--
David Portas
SQL Server MVP
--|||Definitely did not intend to be inconsiderate.
Sorry.
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1130946993.340299.287440@.g14g2000cwa.googlegr oups.com...
> So CROSS-POST if you must. Do NOT multi-post.
> Multi-posting is extremely inconsiderate to those who help you as well
> as likely to be ultimately less productive for you. That's because
> multi-posting divides, weakens and renders redundant the efforts of
> others and makes it more likely they will kill or ignore your posts in
> future. If you don't know how to cross-post then read your manual.
> --
> David Portas
> SQL Server MVP
> --
Friday, February 24, 2012
Database design and development Best Pratice
towards drawing up a Best Practice document that developers can work towards
when develpoing DB's and subsequent applications.
See the below links:-
http://www.extremeexperts.com/sql/ar...Practices.aspx
http://www.sql-server-performance.co..._practices.asp
Thanks
Hari
SQl Server MVP
"simlr" <simlr@.discussions.microsoft.com> wrote in message
news:219CCD01-B653-4246-B20C-78D536BF4D3C@.microsoft.com...
> Can anybody point me in the right direction on any resoures that may help
> us
> towards drawing up a Best Practice document that developers can work
> towards
> when develpoing DB's and subsequent applications.
Database design and development Best Pratice
towards drawing up a Best Practice document that developers can work towards
when develpoing DB's and subsequent applications.See the below links:-
http://www.extremeexperts.com/sql/a...tPractices.aspx
http://www.sql-server-performance.c...t_practices.asp
Thanks
Hari
SQl Server MVP
"simlr" <simlr@.discussions.microsoft.com> wrote in message
news:219CCD01-B653-4246-B20C-78D536BF4D3C@.microsoft.com...
> Can anybody point me in the right direction on any resoures that may help
> us
> towards drawing up a Best Practice document that developers can work
> towards
> when develpoing DB's and subsequent applications.
Database design and development Best Pratice
towards drawing up a Best Practice document that developers can work towards
when develpoing DB's and subsequent applications.See the below links:-
http://www.extremeexperts.com/sql/articles/BestPractices.aspx
http://www.sql-server-performance.com/vk_sql_best_practices.asp
Thanks
Hari
SQl Server MVP
"simlr" <simlr@.discussions.microsoft.com> wrote in message
news:219CCD01-B653-4246-B20C-78D536BF4D3C@.microsoft.com...
> Can anybody point me in the right direction on any resoures that may help
> us
> towards drawing up a Best Practice document that developers can work
> towards
> when develpoing DB's and subsequent applications.