#mysql
11 November 2007
Total 18 pages. You are browsing page 2/18.
First :: Prev :: [1] [2] [3] [4] [5] [...] :: Next :: Last
01:05 <****> whut ?
01:05 <****> you have..whut ?
01:05 <****> aaargh
01:05 <****> Database normalisation comes up next...
01:05 <****> okay, short, sharp SQL lesson here:
01:05 <****> you DO NOT, never, store the same thing repeatedly
01:05 <****> eh? I'm not?
01:05 <****> you use a *reference* or crosstable
01:06 <****> I'm not storing repeat values?
01:06 <****> Each building is different...
01:06 <****> yes, you are - horribly so, even
01:06 <****> building_1 contains the building level for that building etc
01:06 <****> building_2 contains the level for that building (a different building)
01:06 <****> this isn't repeat information...
01:06 <****> yes, it is - they're all buildings
01:06 <****> How else do you suggest I store building levels :|
01:06 <****> so you use a crosstable that holds isles and buildings
01:06 <****> I am telling you how
01:07 <****> the rest is reading
01:07 <****> anyone know the my.cnf setting for default engine type?
01:07 <****> !man default engine
01:07 <****> A crosstable would be a seperate table that contains the building levels right?
01:07 <****> Nothing found.
01:07 <****> oktanouc: An example would be a separate table like isle_building which has the columns (isle_id, building_id, user_id, level) would work, with a PK over isle_id and building_id
01:07 <****> oktanouc no, it is a separate table that holds the references to the buildings and the isles
01:08 <****> Your `isle` table would then not need the building_x columns
01:08 <****> so the isles table has NO references to buildings in it
01:08 <****> ergo is more efficient, smaller, and oh yeah - not braindead
01:08 <****> I'm not seeing the advantages of this, the buildings are always looked up with the isle information...therefore I cannot see why they should be stored in a seperate table?
01:08 <****> I'm never just going to lookup the building levels, always all the isle data
01:09 <****> because you chose to use a relational database to store them in - so you abide by its rules
01:09 <****> if you don't, you get to keep both pieces :)
01:10 <****> that's right - I am implying that it *will* break, not *may* break
01:10 <****> somewhere along the line, usually at or past the poit where making changes to your database means starting from scratch...
01:10 <****> sorry, I'm pretty confused
01:11 <****> Please explain how it will break :|
01:11 <****> Excuse...I'm a total n00b
01:11 <****> well, what happens when you need to add another building ?
01:11 <****> I dont need to add another building
01:11 <****> its a game, the game doesnt change halfway though
01:11 <****> that's nonsense
01:11 <****> its an everlasting game
01:11 <****> okay, I'm done
01:12 <****> I assure you, a new building does not need to be added
01:12 <****> He's saying that eventually your database design will break when you make _one_ little change, like adding a building or a new attribute to a building. You will then need to redesign the database and the code
01:12 <****> I don't mind if you're new to SQL, at all - but you do have to be able to accept experience from people who have some
01:12 <****> Sorry yes, I'm not saying your wrong
01:12 <****> I'm trying to pickup where I'm lacking
01:13 <****> If I wanted to add a new building (if...I dbout I ever would)
01:13 <****> whats wrong with a simple alter table?
01:13 <****> Because it then affects the php code
01:14 <****> Only the bit which controls that building...
01:14 <****> which would still need to happen if I operated the buildings under a seperate table anyhow
01:14 <****> ...which is almost every other bit, in a decent game
01:14 <****> and displays it
01:14 <****> oktanouc no, that's not true
01:14 <****> it's provably false, period
01:14 <****> It is in my code :|
01:14 <****> that's exactly what SQL is good at
01:15 <****> then your code is also quite dangerous :)
01:15 <****> In no game do all buildings operate the same
01:15 <****> If you had a php class building, for example. You could add in the functions load, at and size. Then iterate over all buildings as needed. Adding a new building wouldn't necessarily affect anything at all
01:15 <****> therefore surley code is going to have to be changed per building
01:17 <****> oktanouc, stuff like (to take typical strategy examples) the HP of a given building could be stored in the database.
01:18 <****> My game isn't that type
01:18 <****> oktanouc, plus, say, recruitment lists, etc. Of course if you want totally new functions you'll have to code them in.
01:18 <****> the only thing that changes with buildings is the level
01:18 <****> oktanouc, anyway, I agree with you that this doesn't necessarily need to be in the DB.
01:18 <****> It's not the kind of thing, normally, that would necessarily be easy to abstract like that.
01:19 <****> I mean, it can be and is, but you don't really have to if you don't want to. Ask in a database chat and they tell you to add everything to the database, I suppose. :)
01:19 <****> Aye, no offense but I think some of you guys are a tad biased towards mysql
01:20 <****> I really can't see how my code will break if I edit the table structure that minorly
01:20 <****> oktanouc: Forget the database for a moment, you would never want to have hard coded attributes per building in your code. That is a very bad way to design your application. The structure suggested above by most of the comments simply reflects the way you should be building/designing your application and the database that would make that easiest.
01:20 <****> It won't, every changing app needs schema changes sometimes.
01:21 <****> Xgc: The buildings arn't hard coded, there all definable by variables within the code
01:21 <****> oktanouc: and property files, while not a terrible thing for the most trivial application, have almost no place in a database driven game/application.
01:21 <****> And as I said, the only changable thing per building is the level and name
01:21 <****> Xgc, as long as it's defined once, in constants or whatever, what's the problem? You could always add more and more and more stuff to the database. You shouldn't put things in that you expect will change essentially never, and that sysadmins don't have to be able to change.
01:23 <****> oktanouc: The benefit to ahving a common method of handling you data will outweigh any simplification you think you gain by having a property file and denormalized tables. Just about the only reason you might choose the denormalized form would be performance. There's no chance you have a performance issue here.
01:23 <****> The thing I'm worried about is although I can see the slight advantages of having it more moduler by using a seperate buildings table its going to make my application slower
01:23 * Simetrical likes the simultaneity of those messages, for the irony
01:23 <****> ie rather than doing 1 query to update buildings I need to do two updates on multiple tables
01:23 <****> for example I need to update the building level in the buildings table and update the isle score in the isles table
01:24 <****> oktanouc, what was your original question, anyway?
01:24 <****> Should I store building names in a seperate table
01:24 <****> oktanouc: You'll see no performance problem at all, not with this small amount of data.
01:24 <****> rather than a php config file
01:24 <****> It won't be small when the game is running
01:24 <****> hundreds of users updating buildigns...thats double the amount of querys than there would be if I were to do it my current way
01:25 <****> 200 querys rather than 100 (exagerated yes) but the principle is the same
01:25 <****> oktanouc: Then describe your design more completely. All I believe you've said is 10 building columns per isle table. How much data does this represent?
01:25 <****> the difference is large
01:26 <****> Xgc: Yes that is correct, I'm unsure of what you mean by how much data does this reperesent?
01:26 <****> It represents the level of each building
01:26 <****> when a building is udpated this level is altered
01:26 <****> the name is never altered during gameplay
01:26 <****> oktanouc: Then I don't see the issue at all. How do you think this slows down your game?
01:26 <****> Therefore from what i'm seeing I see no reason to store it in a database...which to me have always been looked at to store data which changes
01:27 <****> Xgc: Because when someone updates a building an update is done on your proposed building level table
01:27 <****> and an update on the isles table to update the score
Total 18 pages. You are browsing page 2/18.
First :: Prev :: [1] [2] [3] [4] [5] [...] :: Next :: Last