Showing posts with label scenario. Show all posts
Showing posts with label scenario. Show all posts

Friday, March 30, 2012

More Questions....Relationships

Ok heres the scenario:

3 tables

Movie - MovieID, MovieName, Starring1, Starring 2, Director

Director - MovieID, DirectorID, DirectorName

Actors - MovieID, ActorName

In bold are the names of the tables --

in bold+italic are the PK - Primary Keys.

Ive tried to create a relationship between:

1. Movie - MovieID to Director -MovieID - Movie is related to the director

2. Actors - MovieID to Movie-MovieID - Actor is related to Movie

Second relationship failed for some reason.

Im trying to achieve this result:

Movie = Pulp Fiction

Director = Quentin Tan

Actor = Sam L Jackson

Once i do reports etc.....What am i doing wrong here as i think its my relationships im having difficulty with?

Thank you in advance

try:

Select movieName,

DirectorName,

actorName

from movie m

join director d

on m.movieId = d.movieId

and m.movieName = 'Pulp Fiction'

and d.directorName = 'Quentin Tan'

join actor a

on m.movieId = a.movieId

and a.actorName = 'Sam L Jackson'

an alternative is:

Select movieName,

DirectorName,

actorName

from movie m

join director d

on m.movieId = d.movieId

join actor a

on m.movieId = a.movieId

where m.movieName = 'Pulp Fiction'

and d.directorName = 'Quentin Tan'

and a.actorName = 'Sam L Jackson'

|||Thanks but am i on the right lines about creating these relationships in the way i described or would you do anything differently?|||

Assuming that a movie has only one director, something like this:

Director -- DirectorID (PK), DirecorName

Actor -- ActorID (PK), ActorName

Movie -- MovieID (PK), MovieName, DirectorID

Cast -- MovieID, Order, Part, ActorID, (PK: MovieID, ActorID, Part)

The "Cast" table is necessary so that you can list all of the actors of the movie. I added in "Order" so that you can control "Promotion Order" or "Billing Order" or whatever you want to call it -- it is a control so that you can control the order in which the actors might be listed in credits.

I added in "Part" for movies in which somebody like Eddie Murphy might play multiple parts.

From my perspective the biggest problem here is the "Cast" table as I have made it. I still don't feel that it is general enough. For instance, say that you want to use this as the basis for listing movie credits. You want to include Producers, stunt coordinators, etc. It would be best to generalize the "Cast" table into a "Role" table and along the way establish "Subcategories" of the "Role" table. But now we are getting ahead of ourselves. This should get you started.

Monday, March 19, 2012

Monitoring replication from subscriber

Hi,
I have a replication scenario where multiple laptops merge replicate with a
central server. The subscriptions are set up as push subscriptions on the
distributor. My users want a tool to tell when they last replicated, and if
possible, how many records are waiting to be replicated. They need this
while disconnected from the server. Is there a way to get this information,
without having access to the publisher/distributor?
Thanks,
John Loveland
John,
have a look on my site for a script to find pending merge changes. There is
some discussion about the reliability of the data in it, but I've found it a
useful bit of data to use.
For the last time merged using a push, perhaps look at
sysmergesubscriptions.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Paul,
Thanks. That looks like exactly what I need.
John Loveland
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:%23A7Ma05FGHA.2568@.TK2MSFTNGP10.phx.gbl...
> John,
> have a look on my site for a script to find pending merge changes. There
> is some discussion about the reliability of the data in it, but I've found
> it a useful bit of data to use.
> For the last time merged using a push, perhaps look at
> sysmergesubscriptions.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>

Monday, February 20, 2012

MOM Report Integration with Sharepoint Portal

All,
I work for a partner, and we use MOM 2005 in a "managed services" scenario
to monitor client environments, and are attempting to develop client-facing
sites within Sharepoint portal to display various reports and alert information.
This effort spawned the following question:
What would be the best way to provide a MOM "State View" (green/yellow/red)
within a Sharepoint site. I cannot find the state data within the Onepoint
database (nor any reference in the MOMSDK), nor any existing SPS web part
to fit the bill.
Any pointer to where in the database this data lies or opinions on the best
way to address the challenge would be appreciated.
Thanks,
PetMOM 2005 comes with a range of Reporting Services reports, probably
including the one you want. With Reporting Services SP 2, there comes 2 web
parts for SharePoint, the Report Explorer and the Report Viewer. So what you
can do is to set up Reporting Services, and then install the two RS Web
parts to your SharePOint site, and point the reports you want to see. I
think you can use the Report Viewer to show just one report, so you don't
show everyone all the other MOM reports.
Kaisa M. Lindahl
"Pete Zerger" <pete.zerger@.nospam.gmail.com> wrote in message
news:7e9e9bb33a01d8c792709c6ecd86@.msnews.microsoft.com...
> All,
> I work for a partner, and we use MOM 2005 in a "managed services" scenario
> to monitor client environments, and are attempting to develop
> client-facing sites within Sharepoint portal to display various reports
> and alert information. This effort spawned the following question:
> What would be the best way to provide a MOM "State View"
> (green/yellow/red) within a Sharepoint site. I cannot find the state data
> within the Onepoint database (nor any reference in the MOMSDK), nor any
> existing SPS web part to fit the bill.
> Any pointer to where in the database this data lies or opinions on the
> best way to address the challenge would be appreciated.
>
> Thanks,
> Pete
>