Database

Re: Group ranking or row number

29-Mar-10 9:36

I would think you could use a case statement to accomplish that but that is probably not the best way.

Humble Programmer

Mycroft Holmes29-Mar-10 18:48

Mycroft Holmes

29-Mar-10 18:48

This will make interesting reading[^] for you. Also look into PARTITION and RANK, that will allow you to rank the records over the group

Never underestimate the power of human stupidity
RAH

How do you handle Dev DB vs Production DB?

programmervb.netc++29-Mar-10 9:22

Re: How do you handle Dev DB vs Production DB?

29-Mar-10 9:22

When I first started working at my job we maintained local DBs for development on our own machines...so there was alot of upkeep backing up production data restore etc.
Then we had a spare server laying around so we started to use it as the devDB.
Now the server is being used for other purposes so we are back to square one which takes alot of time.
Does anyone have any suggestions of a better way to do this?
FYI we are using mySQL.

Humble Programmer

PIEBALDconsult29-Mar-10 18:09

PIEBALDconsult

29-Mar-10 18:09

Development servers. Every time.

programmervb.netc++ wrote:
backing up production data restore

Never did that; always generated test data -- it's repeatable.

Re: How do you handle Dev DB vs Production DB?

programmervb.netc++29-Mar-10 18:35

Re: How do you handle Dev DB vs Production DB?

29-Mar-10 18:35

I would think it would take more time to generate the amount of test data we need than it would to do backup restore...
Are there tools for this?

Also one reason the data being REAL data matters is because we are converting all apps from Access to mySQL and VB6 to VB.NET so we are running our reports against old and new data to make sure we did not screw up a conversion or the new/better ways we are writing the SQL.

Humble Programmer

Mycroft Holmes29-Mar-10 18:54

Mycroft Holmes

29-Mar-10 18:54

3 Servers is a requirement, dev, uat and production. If/when we have a major deployment and can sync all the servers from production we do this. It does not happen very often as the development almost never stops so all the servers have different versions. But then we have something like 14 apps under production.

We also have another server for bug tracing, take a snapshot of the production server and chase down the problem.

We also use SQL compare and data compare to do deployment, greatest time save ever for deployment.

Never underestimate the power of human stupidity
RAH

Database design question

Alivemau529-Mar-10 4:00

29-Mar-10 4:00

I have a table of football matches, and each match can have 5 different statuses:
Not started, 1st halftime, Break, 2nd halftime, Ended

My question is, what is the correct way of modeling this?:

Matches (MatchId, Status, ...)
where Status is an integer or a string corresponding to each status

vs

Matches (MatchId, StatusId, ...)
where StatusId is a foreign key to MatchStatuses,
MatchStatuses (MatchStatusId, Description)

vs

Matches (MatchId, StatusId, ...)
where StatusId is a foreign key to MatchStatuses,
MatchStatuses (MatchStatusId, Description, IsNotStarted, IsFirstHT, IsBreak, IsSecondHT, IsEnded)

for example, a registry in this case would be: (1, "First Half time", false, true, false, false, false)

THANKS!

J4amieC29-Mar-10 4:56

J4amieC

29-Mar-10 4:56

I would go with 1 (ok solution) or 2 (better solution)

Solution 3 was just dumb to the max.

Alivemau529-Mar-10 5:01

29-Mar-10 5:01

With (1) you would have to hardcode any combobox (for example) containing the different possible entries.

With (2) you wouldn't know which one is each..

Diff between 2 and 3 would be that in the program itself you would have to use:

someMatch.Status.Finished == true
vs
someMatch.Status.Description == 'finished'

But im not convinced, though, of solution (3)

J4amieC29-Mar-10 5:17

J4amieC

29-Mar-10 5:17

Alivemau5 wrote:
With (2) you wouldn't know which one is each..

public enum MatchStatus
{
  NotStarted = 1,
  FirstHalf = 2,
  HalfTimeBreak = 3
  //.. etc
}

If you have code relying on this, the enumerate it in code.

Alivemau529-Mar-10 6:24

29-Mar-10 6:24

You have convinced me.

And for users privileges do you think its a good idea to have the following?:

Users (UserId, UserTypeId, ..)
UserTypes (UserTypeId, Name, MayAddMatch, MayDelMatch, May..., May.., May... )

with registries like (1, "Admin", true, true, true...)

(i'm not doing an offtopic.. its a similar question)

programmervb.netc++29-Mar-10 9:11

29-Mar-10 9:11

Alivemau5 wrote:
With (2) you wouldn't know which one is each..

You could know which one is which this is how we do it.
This may not be the cleanest way but it is very easy to maintain.
We create an integer array such as Dim blah() as Integer and set a default size for it close to what we think the number of records will be to minimize the use of redim.
Then do something like this with the record set you retrieve.

While myReader.Read
            cmbControl.Items.Add(myReader.GetString(1))
            lKeyIndex(lIndex) = myReader.GetValue(0)
            '
            lIndex += 1
            ' see if we need to redimension the array...
            If lIndex Mod iCurrentDim = 0 Then
                iCurrentDim = iCurrentDim + iDefaultDim
                ReDim Preserve lKeyIndex(iCurrentDim)
            End If
End While

Here is a example query.

SELECT `UniqueNumber`, `Description` FROM `ct_contsources_master` WHERE `Inactive` = 0 ORDER BY `Description`

Notice the Inactive flag...
If you use this than if a row is no longer valid you can set it to 1...therefore not populate the combo.

EDIT..
Oh yeah this will help..

Public Function fiSetComboIndex(ByVal lKey As Long, ByRef cboControl As ComboBox, ByRef lKeyIndex() As Long) As Integer
       ' this routine sets the current "SelectedIndex" to the lKey passed in...
       Dim iII As Integer
       Dim iKeyIndexLength As Integer = lKeyIndex.Length - 1
       '
       fiSetComboIndex = 0
       For iII = 0 To iKeyIndexLength
           If lKeyIndex(iII) = 0 And iII > 0 Then
               Exit For
           End If
           If lKeyIndex(iII) = lKey Then
               fiSetComboIndex = iII
               Exit For
           End If
       Next
   End Function

Use this to get the value that is selected.

blah(comboBoxName.SelectedIndex)

Store the result of that in the main table.

Humble Programmer

riced29-Mar-10 5:57

riced

29-Mar-10 5:57

Depends on what questions you want to answer.
If the only question you want to answer is 'What is the status of a match?' then first suggestion is good enough. This effectively means you have a one-one relation between matches and statuses.

If you want to answer questions like 'What were half-time and full-time scores of a match?' then you have a one-many relation between matches and statuses so you need to use your second suggestion.

Your third suggestion seems to offend first order normalization.

I'd go for the second approach because it's more flexible. This may also mean moving some columns from Matches into the statuses table (e.g. the score since you have both half and full time scores).

Regards
David R
---------------------------------------------------------------
"Every program eventually becomes rococo, and then rubble." - Alan Perlis

Alivemau529-Mar-10 6:30

29-Mar-10 6:30

Well my second suggestion was more like a table with 5 registries than a table with n registries, that is:

(1, Not started)
(2, First Half)
(3, Break)
(4, Second half)
(5, Ended)

And no more columns.. not this:
(1, Not started)
...
(23, Not started)
I think you understood that

This second suggestion was thinking on that I could fill any later combo (for example) without hardcoding it.. but the enum solution works and I wouldnt need to hardcode.

Eddy Vluggen29-Mar-10 7:01

Eddy Vluggen

29-Mar-10 7:01

Alivemau5 wrote:
My question is, what is the correct way of modeling this?

Normalization[^] would be the way to go, with most tables ending up in the third normal form.

A joking reference during design would be "The Key, the whole Key, and nothing but the Key, so help me Codd[^]" Smile | :)

I are Troll Suspicious | :suss:

programmervb.netc++29-Mar-10 8:53

29-Mar-10 8:53

I say 2 because that would be normalized. The enum would prevent hard coding but you really don't want to have to refer to app anytime you want to know what the value is...
For instance if you are just looking at the data in the table not in the app.
Also if you do it the second way rather then the enum you don't have to modify the enum every time you add a row.

Humble Programmer

PIEBALDconsult29-Mar-10 18:12

PIEBALDconsult

29-Mar-10 18:12

The second way, definitely -- plus an enumeration in your code.

P.S. See my GenOmatic[^].

Alivemau530-Mar-10 10:44

30-Mar-10 10:44

Isn't bad that the table with states would be finite (5 registries) and readonly?