7

Got a question and wanted to get the best practices or thoughts on this.

I have an application that was developed with a SQL Server back end (site is Entity framework, vb.net, asp.net). The original design does not have a database diagram/schema/relationship table in the db itself.

The site works great but have gotten some pushback from another group that says it has to have a relationship table in order to work properly.

So is this personal preference or what? I'm not a DB guru and trying to find out if it's two ways of development and someone is trying to push personal preference over standards or best practices.

MDCCL
  • 8,530
  • 3
  • 32
  • 63
Valien
  • 745
  • 3
  • 7
  • 14

4 Answers4

6

You don't need a diagram for it to work, you need one to train the future developers!

However, if what you really have is a database with no actual formal PK/FK relationships set up (Which you can do when creating diagrams as well as through better ways such as SQL scripts), then that is a different story. That is something that will eventually cause your data to be inconsistent and is a real problem indeed to other users of the database.

HLGEM
  • 3,153
  • 18
  • 18
3

If it's a purely object driven data design, you can't really query it except through application code anyway. So no, I wouldn't ask for a data diagram that's not going to do me any good, no. I think that sounds like someone pushing preferences over standards (and that's coming from a pretty committed standards oriented DBA nerd).

Grant Fritchey
  • 4,615
  • 20
  • 19
3

It's certainly not required for any functional reasons, but it's not a bad idea for some quick and dirty documentation. It sounds like they're confusing it with the Access relationship designer, which is where you actually declare your foreign keys. The SQL Server database diagram designer looks similar, but has a completely different purpose (documentation rather than DDL).

db2
  • 9,708
  • 4
  • 37
  • 58
2

I would recommend having a data dictionary and ER-diagrams for the business domain tables at the very least. While there are some system-generated asp_ tables that are well documented on their own and possibly irrelevant to the business logic, anything that has been created outside of this should be clearly documented.

hqrsie
  • 421
  • 3
  • 4