hi all,
so i have these tables:
Company
Job
Resume
user searches for a company, views that company. there is a list of
"viewed" companies for that user. Users can attach/delete a (private to
themselves) note about that company.
same for jobs and resumes.
What I want to know is, should i have a CompanyNote, JobNote,
ResumeNote table, or have one Note table?
with the first option, can have a foreign key to the corresponding
Company/Job/Resume table, with the second option cannot.
TIA
Neili suppose i should have one note table:
NOTE
noteid
text
a Company table:
COMPANY
companyid
a User table:
USER
userid
and a COMPANY_USER_NOTE table
COMPANY_USER_NOTE
companyid
userid
noteid
and a JOB_USER_NOTE table:
JOB_USER_NOTE
jobid
userid
noteid
then foreign keys not a problem|||(neilmcguigan@.gmail.com) writes:
> i suppose i should have one note table:
> NOTE
> noteid
> text
> a Company table:
> COMPANY
> companyid
> a User table:
> USER
> userid
> and a COMPANY_USER_NOTE table
> COMPANY_USER_NOTE
> companyid
> userid
> noteid
> and a JOB_USER_NOTE table:
> JOB_USER_NOTE
> jobid
> userid
> noteid
> then foreign keys not a problem
But now you can have multiple notes for the same user to the same item.
And the same note can be connected to both job and company.
But maybe that's a feature?
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||would the alternative would be...
table JobNotes:
UserID
JobID
NoteText
and table CompanyNotes:
UserID
CompanyID
NoteText
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns97BB794BC5320Yazorman@.127.0.0.1...
> (neilmcguigan@.gmail.com) writes:
> But now you can have multiple notes for the same user to the same item.
> And the same note can be connected to both job and company.
> But maybe that's a feature?
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pr...oads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodin...ions/books.mspx
Showing posts with label searches. Show all posts
Showing posts with label searches. Show all posts
Monday, March 26, 2012
Friday, March 23, 2012
OLTP vs Decision Support
Whilst on the Nth hour (n = many) of my magical journey through MS Sql BOL I've come across OLTP Vs Decision Support. After a couple of searches here could someone shore up the following for me please...
A decision support database is the same as warehouse database.
This is for static data commonly used for reporting and analysis.
OLTP is a live database (accomodates inserts, deletes, updates etc).
Is that right?
Also would it be fair to assume that a decision support database is generally going to be spawned from the historical data of an OLTP database? Any real world examples of these two terms would be greatly appreciated too.
Cheers
DanOLAP
Yes it comes from OLTP...dimensions, fact tables, star schemas, snowflakes...
All the buzz words...
basically you migrate data from your database to basically a read only version of the data...
You then may also have processes to derive data...and store it...for example all the sales for department stores for the month
You derive the data by state, by day, whatever...
However people need to see data that's what you build...
Now query is a lot faster because the work has already been done for the end user...
google up some non platform specific concepts...|||OK, makes sense and I only had to read it twice!
Cheerssql
A decision support database is the same as warehouse database.
This is for static data commonly used for reporting and analysis.
OLTP is a live database (accomodates inserts, deletes, updates etc).
Is that right?
Also would it be fair to assume that a decision support database is generally going to be spawned from the historical data of an OLTP database? Any real world examples of these two terms would be greatly appreciated too.
Cheers
DanOLAP
Yes it comes from OLTP...dimensions, fact tables, star schemas, snowflakes...
All the buzz words...
basically you migrate data from your database to basically a read only version of the data...
You then may also have processes to derive data...and store it...for example all the sales for department stores for the month
You derive the data by state, by day, whatever...
However people need to see data that's what you build...
Now query is a lot faster because the work has already been done for the end user...
google up some non platform specific concepts...|||OK, makes sense and I only had to read it twice!
Cheerssql
Subscribe to:
Posts (Atom)