Create the SQL commands to create the tables in Oracle.

[greut]

Running it from the command line.

$ sqlplus nba/nba@XE < schema.sql 

[nddrylliog]

Is there an easy way to run Oracle SQL completely on Linux? (Server+Client)

Just curious.

[greut]

I do but it's not super easy because it only comes as rpm and requires strange stuff to install. In other words, it doesn't give a shit about any linux way of managing an app. They recommended us to use a VM.

[nddrylliog]

Okay, so Windows it is.

[greut]

VM for Windows as well... Uninstaling it can be tricky!

[nddrylliog]

Oh really? How crapalicious. The name of this project is becoming more and more fitting.

[greut]

btw, this schema is on our DB.

[greut]

I'm almost done here but there are two things I'm not super happy with:

• the 3 player_*_seasons tables could be one table only with a type switch;
• are the seasons reals entities? 1997 really means "1997-1998".

Can you take 3 minutes to dive in and give some feedback, btw #2 and doing the deliverable are remaining.

kthxbai

[nddrylliog]

About type switches: were those seen during the course?

As for years, I think it's alright to store them as 1997, the real meaning is implicit.

[greut]

I've made three tables but they look the same and could be one with a parameter (like enum): playoff, regular or allstar. It'll show up doing #2 anyways, which I won't do.

Ok, for the Season, let's KISS :-)

[nddrylliog]

For the enum / parameter etc. I think we did see differences in the columns, ie. they didn't look exactly the same and we would have had to have 'dead columns' in some tables. But I might be mistaken, @sebasti4n do you remember what was our conclusion on that?

[greut]

It's not my point here. Do the point 2, you'll see what I mean (I guess).

On mar 20 mar 2012 00:19:42 CET, Amos Wenger wrote:

For the enum / parameter etc. I think we did see differences in the columns, ie. they didn't look exactly the same and we would have had to have 'dead columns' in some tables. But I might be mistaken, @sebasti4n do you remember what was our conclusion on that?

---

Reply to this email directly or view it on GitHub: https://github.com/nddrylliog/crap-sql/issues/3#issuecomment-4586034

[nddrylliog]

I would do point #2 if I knew what to do.

[greut]

Lulz, I'd do something UML-likey but it's not very clear to either. I was hoping you'd know :-D

On mar 20 mar 2012 00:34:24 CET, Amos Wenger wrote:

I would do point #2 if I knew what to do.

---

Reply to this email directly or view it on GitHub: https://github.com/nddrylliog/crap-sql/issues/3#issuecomment-4586221

[nddrylliog]

I can export a PDF containing schema.sql if that's what they want...

On Tue, Mar 20, 2012 at 12:41 AM, Yoan Blanc < reply@reply.github.com

wrote:

Lulz, I'd do something UML-likey but it's not very clear to either. I was hoping you'd know :-D

On mar 20 mar 2012 00:34:24 CET, Amos Wenger wrote:

I would do point #2 if I knew what to do.

---

Reply to this email directly or view it on GitHub: https://github.com/nddrylliog/crap-sql/issues/3#issuecomment-4586221

---

Reply to this email directly or view it on GitHub: https://github.com/nddrylliog/crap-sql/issues/3#issuecomment-4586307

Amos Wenger Lead Developer official.fm, founder ofmlabs.org I'm @nddrylliog https://github.com/nddrylliog on GitHub

[greut]

Maybe something in-between tasting nice OOP. Although our ER diagram doesn't have much constraint yet...

[greut]

Something like that? http://www.db-main.be/sites/db-main.eu/files/LOGIC.jpg

[nddrylliog]

Are you suggesting we use db-main or just make a similar graph?

I've taken a look at the db-main tutorial, but I really don't want to install db-main 6.5 anywhere. Seriously ___

[nddrylliog]

FYI, it wasn't obvious to me so I documented credentials here: https://github.com/nddrylliog/crap-sql/blob/master/documents/credentials.md

(And now installing SQL Developer..)

[nddrylliog]

@greut I've given it more thought (and am knee-deep into the logical schema or whatever it's called, ie. #2) and I think the enum is a good idea. I'll make my diagram as if it was an enum already and then you can change the SQL whenever you feel like it :)

[nddrylliog]

@greut Should the PLAYER_SEASONS table really reference PEOPLE (through PERSON_ID) or should it reference PLAYERS (through PLAYER_ID) ? I'm wondering.

[nddrylliog]

@greut same question for DRAFTS, maybe it should reference players instead of people.

[SeZuo]

@sebasti4n do you remember what was our conclusion on that?

If I remember correctly our discussion was more about "do we use a thin or fat database" - and thin was our choice when we merged the career with the season tables.

I've just checked for unique columns in all tables and there are some. Teams have the following unique stats:

• pace
• won
• lost Players have those:
• gp
• minutes

There is no divergence between the three player_*_seasons, however there is between the two relations "offensive" and "defensive" relations.

I'll commit the file as soon as I figure out how to do it.

[SeZuo]

@greut Should the PLAYER_SEASONS table really reference PEOPLE (through PERSON_ID) or should it reference PLAYERS (through PLAYER_ID) ? I'm wondering.

DRAFTS and PLAYER_SEASON both are referencing players and should, in my opinion, point to the PLAYERS table.

PLAYER_SEASON should never hold an entry to a non-player person. Both paths lead to the same complexity, so we should take the safer one.

[greut]

I agree on everything you said.

About the missing fields, do we add them to Stat or shall we create two kinds of Stat: team and player? I don't mind, really.

The career tables are imho denormalized data (in other words data you can obtain from the rest e.g. blog_entries <-> comments where you store a comments_count in the Entry). That's why I dropped them.

I'll update the ER and SQL schema accordingly, no problems.

[nddrylliog]

@greut For Stat, we can have an "ISA" relationship with two "sub-entities", that works for the er graph at least. For the implementation, I guess we can duplicate columns in both PlayerStat and TeamStat. Hm.

[greut]

:+1: