Sean Lange (1/22/2013)

---

ScottPletcher (1/22/2013)

---

Sean Lange (1/22/2013)

---

GilaMonster (1/22/2013)

---

Sean Lange (1/22/2013)

---

ScottPletcher (1/22/2013)

---

DiverKas (1/22/2013)

---

1) Do NOT let your C#/VB/ASP/Pascal guys design the database.

2) Do NOT let your DBA's design the database.

3) Hire a Data Architect.

Just saying. The first 2 groups have very biased views of how data should be structured for VERY different reasons, neither of which usually solves the entire problem.

#2 is NOT necessarily true -- it depends on the DBA. I have long-term experience in all phases of the design process.

Also, if you hire someone who's solely a Data Architect, then you have to hire an additional person to convert the logical model into a physical model.

Neither is #1. There is no rule that says a developer is unable to design a proper database because they are a developer.

I'm a developer (SQL mostly, not front end). I'd argue that I can design at least a passably good database.

Gail we are saying the same thing. I think anytime someone starts segregating abilities based on job title they are destined to get snowballed. I too am a developer and would like to think I could cobble something usable together.

Perhaps. But I would not want someone who had not been a full-time database designer or DBA at some point to head a db design. Based on my past experiences, (almost) pure developers can't seem to forget physical details long enough to do a proper logical design. Any who could do it properly would be the rare exceptions, not the normal rule.

I agree it would be the exception but the "rules" as posted sounded like absolutes and I disagree with that sentiment.