Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We are designing a dimensional model for an IT support business. There are cases (some call them tickets or incidents) with different statuses (feels like an SCD type II dimension)
We also need to consider the count of cases and SLA time duration as measures.
Before going into detailed design, I reviewed Kimbal's data warehousing toolkit but couldn't find a matching business for our project. Are there any references for a dimensional model for this type of business
From your limited information it sounds like you want to model as an accumulating snapshot fact (as well as a transaction table). See Insurance claim processing pipeline in Kimbal's The Data Warehouse Toolkit.
It would only be a Type II SCD if the dimension entries were being updated, which in your described case they are not (you are updating the Fact table)
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I work for a firm with a relational database. Some of my colleagues once told me that storing data directly on relationships (and not on entities) was a bad pratice. I can't remember why. Can you help me with that ? Do you agree ? What are the risks ?
Many thanks !
No, this is not a bad practice. In fact, "relationships" are often entities themselves. For instance, an "order" might relate a "person" and "store". It would also naturally have other information such as when the purchase happened, the payment amount, the total amount, and so on.
In general, when I create tables in SQL, I include information such as:
createdAt -- the date/time the row was created
createdBy -- who created the row
createdOn -- the system where the row was created
This would be true on all tables, even those representing many-to-many relationships.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
How to Create optimal database design by looking at below invoice of XYZ Ltd. stationary store, also show all possible tables including relationships.
Here's the approach you should take.
Look through the form to figure out what fields should exist.
Determine the relationships between those fields; i.e. do they relate to the same thing (e.g. the invoice, an invoice line, an item, etc) as other fields.
Figure out the relationships between those things (i.e. can an item appear on more than 1 invoice / can an item appear more than once on the same invoice / is there a 1:1 relationship between them?
For each "thing", create a table. That table should have those fields directly associated with that thing defined on it, along with any useful additional fields (e.g. primary key).
For each "thing" create required relationships between its fields and the related tables' fields.
Good luck.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am about to develop a small cms\forum. Multiple customers are going to have there own access where the customers can communicate white them.
What is best practices- to make separate SQL db to each customer's cms data or one big to contain all the customers data?
As I cannot comment, so I can only type here.
It is strange that you would like to have separate database for each customer and it seems impossible to manage multiple db for just one purpose or function. For example, how could you identify which db belong to which customer? Also, do you expect to have many resource to allocate to each customer? a db simply waste if the customer is not active.
So, I suggest you to use one db to manage all the customers data which is normal solution.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Apologies in advance if this is a stupid question. I've more or less just started learning how to use SQL.
I'm making a website, the website stores main accounts, each having many sub-accounts associated with them. Each sub-account has a few thousand records in various tables associated with it.
My question is to do with the conventional usage of databases. Is it better to use a database per main account with everything associated with it stored in the same place, store everything in one database, or an amalgamation of both?
Some insight would be much appreciated.
Will you need to access more than one of these databases at the same time? If so put them all in one. You will not like the amount of effort and cost 'joining' them back together to do a query. On top of that, every database you have needs to be managed, and should you need to transfer data between them that can get painful as well.
Segregating data by database is a last resort.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
A version control system compares the scripted definition of a table to the checked in state. So I guess many cvs will see column reordering of a table as a change.
Since tsql does not support to add a new column in the middle of a table and because in a relational DB the ordering should not matter, what are good practices for version control of table definitions if the column-order could change.
Sometimes you could need to redo a drop column in the middle of a table.
You should be storing scripts to setup your database in source control, not trying to have something reverse-engineer those scripts from the state of the database. Column-order then becomes a non-issue.
Specifically, I've seen two schemes that work well. In the first, each database schema update script is given a sequential number, and the database tracks which sequence number is the last applied. In the second, each database schema update script is given a UUID, and the database tracks all UUIDs that have been applied.
I would checkout the book Refactoring Databases for more details and examples of how to manage database changes.