Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Link of the day: on the importance of a good data model

Chacham (981) writes | more than 5 years ago

User Journal 8

Post about a post abut a post.

Toon Koppelaars blogged about Robyn Sands blog about Bert Scalzo's recent article "Is Data Modeling Still

Post about a post abut a post.

Toon Koppelaars blogged about Robyn Sands blog about Bert Scalzo's recent article "Is Data Modeling Still Relevant?".

Bert's article is excellent. Robyn's post and the following comments are amazing. It's like John Brady worked on our team.

Think about it, read it and you have read a post about a post about a post about a post. Think of the potential!

cancel ×


Sorry! There are no comments related to the filter you selected.

And absolutely relevant (1)

Marxist Hacker 42 (638312) | more than 5 years ago | (#28224573)

I'm working my way through a database done by young programmers who claim to be trained in Object Orientation, but not database modeling.

To insert just ONE top-level record (a company in a resource-allocation database) I need to figure out a way to insert three records in three different tables:
1. an object record- which contains a *globalized* serial primary key covering several tables.
2. the company record
3. the main office record (which is *REQUIRED* by a 1:1 foreign key assignment)

Third normal form this is NOT.

Re:And absolutely relevant (1)

Chacham (981) | more than 5 years ago | (#28226183)


I feel your pain. :(

The problem is two-fold: (1)

Bill Dog (726542) | more than 5 years ago | (#28231881)

1) We have Extreme Programming, and things like it. Where you do the minimum to accomplish the requirements, as they are *today* -- it's counter to the philosophy to design in things for the future.

2) We don't have DBA's, or people like them. Most places I've worked kept costs down by omitting them. So you get databases with no constraints applied, and programmers wasting time adding code to the application to deal with nonsensical kinds of data that should never be coming back from the backend. IMNotSoHO, you don't for example let mathematicians design the code, and you don't let programmers design the database. I've seen completely effed-up designs resulting from businesses doing this.

Is this anything like... (1)

huckda (398277) | more than 5 years ago | (#28247145)

being the Dude playing the Dude who was the Dude?

As a serious business user (1)

tqft (619476) | more than 5 years ago | (#28275711)

(well before I became unemployed)
having to ask where and how the database captures these business critical measurements sucks.

We get an original set of numbers daily and at the end of the month a verified statement. And as expected there are differences. This was known, incorporated into the design and failed to produce the correct outcome (how much gas we bought and sold in a month).

I had to go back to the boss and have him ask the consultants - where is the data model so we can verify the numbers, trace the differences between original and final and have everything match up so we can pay our invoices and bill our customers.

There was no data model - the data was captured in the database and supposedly the rest was captured in the business logic/code. That's right the Settlement/Financial/Auditors would have to read the code to figure which number to get from where.

Then I had to go and make a data model. And the lead consultant and I had been getting on so well before then.

Re:As a serious business user (1)

Chacham (981) | more than 5 years ago | (#28277465)


Good story though.

I'm currently on a project we're we'll be dealing with thousands of financial statements, processing and verifying them for use within reports and the like. We have to have a history of changes, right from the submitted statement. As this is financial, we have to get it right.

I find it odd and disturbing that there was a financial system without a decent model. Do those who code on the fly really think a model is *never* needed?

Re:As a serious business user (1)

tqft (619476) | more than 5 years ago | (#28284827)

I think they saw the specialist knowledge required to produce reports as a future income stream, hence using the code as the business model.

Paul the boss was very displeased when I pointed there was no document other than code - there were ppt files with boxes and lines pointing from external data sources to database, but no names or fields.

But nothing that could be interpreted as final_daily_value at meter_X is held in table Y and is used by process Z (well it wasn't used in process Z was the problem - in testing as the first monthly invoices came in they didn't match up).

The "financial system" had a decent model internally large system provided externally (not SAP) used in many commodity trading and financial houses. The "without a decent model" bit seems to have been overlooked in the implementation of the specification (damn sure it was in there as I put it in), or was on the bottom of the to do list as the consultants struggled to hit target (read payment) dates.

Re:As a serious business user (1)

Chacham (981) | more than 5 years ago | (#28291159)

I wonder if it would be helpful it there were DBAs/DAs for hire offering Data Modeling services. Turn it into an art form that can be sold as a service. Normally, when a DB is used, there should be a modeler on the team, but that isn't always practical. Perhaps then, for those teams that only have programmers, they can view the Data Model as something that needs to be done by someone other than them, and have the team lead/supervisor see it as something important to the business.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>