| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Comments:
<0> thank you though
<1> minDscrm: Without knowing how a database like this can be used to your benefit, you really aren't ready. You can't know you need to use a database if you can't use it.
<0> i think the person who was mentionign it was an indian... who looks like a mexican but doesn't mind being spoken spanish too at the taqueira's...
<1> minDscrm: Start the journey by learning what a relational database is and then learn how to use one.
<0> thank you Xgc ... i suppose that's why i'm here asking questions.. i'm glad you cleared this up for me.
<2> You've gotta start somewhere.
<0> i'm set in learning to use a database.. but i'm not sure what for :)
<2> There's no substitute for practice.
<1> minDscrm: Trying to be smart won't help at all. You need to find a good place to start.
<0> Xgc again thanks for your insight
<1> Smart ***? That's a good way to start.
<0> Xgc, i figure 3 books that say mysql on them .... a somewhat shacky knowledge of very basic php is the way to go...
<0> i have lots of data.. but don't know exactly what data is good for databases :)
<0> xgc, take it light heartidly.. it's hard for a beginner to figure out what the hell this stuff is.
<2> minDscrm: Any kind of categorical data.
<0> for instance.. is it good to store whole articles that comprise of multiple pages worth of text ?
<0> today i learned that it's bad to store photos in the db
<2> It's not inherently bad.
<0> what exactly is categorical data... i figure anything and everything can be catergized somehow.
<2> It has advantages and disadvantages.
<3> It is good to store articles of text if you want to search within the text.
<3> If you have no plan on searching within it (just like binary files like pictures), there is no point in adding database overhead.
<0> will, ah.. that makes a little more sense to this thing!
<3> How does that not answer all your questions?
<0> thank you for saying that.. that narrows my scope down..
<2> But there is also the matter of ease of storage and back up.
<0> it cleared up a great deal of vagueness for me
<2> One advantage to storing images in the db is consolidation of data.
<2> But I don't believe it outweighs the disadvantages.
<3> kambei, You should not hinder performance of a DB just to make it easier to back it up.
<3> :)
<2> will: Which is why I don't believe it outweighs the disadvantages.
<3> You said that too late :P
<0> so if i got a lot of data i can enter in... you guys recommend that i use comma seperated values?
<0> and use the LOAD DATA thing/
<3> Whatever is eaiser for you.
<3> I prefer tab
<0> ah tab.. same thing to me at this point
<0> tab, comma.. same thing
<3> Yes.
<0> that's good.. can you explain why you use tabs instead of something else?
<3> Commas you have to worry about quoting your strings if it contains commas.
<3> Usually I don't have tabs in my data
<0> ah okay
<0> wonderful thanks
<3> But I do have commas.
<0> yea, i understand
<0> this is good
<3> This info comes through experience...
<0> i gotta find an example of a tab delimenated file so i can load it up
<0> lemme do a goodle
<0> google
<3> You don't need an example...
<3> aaa[tab]bbb[tab]ccc[tab]ddd\n
<0> but what column does that get put into?
<0> i don't really get it
<0> but i need to read more
<2> It's like this.
<2> you have a table
<2> the first column gets entered into the first column of your table
<2> and so on
<3> Not really.
<1> http://www.w3schools.com/sql/default.asp and any others you can google for, followed by http://www.sqlservercentral.com/columnists/fkalis/coddsrules.asp
<3> You can specify which columns it goes into.
<1> minDscrm: Check those, if you wish.
<2> You can.
<0> thanks xgc, headed that way
<2> I'm just trying to simplify matters.
<0> i know how to setup my tables... and for instance one column is 'lastname' another is 'firstname' another is 'weight' another is 'height' -- so i have like one line of tab deliminated last names... and an other line of tab deliminated first names and another line of tab deliminated weights and anotehr line of tab deliminated heights .. it should worok?
<0> i need to read.. but you get my drift..
<0> it's hard starting out from ground zero :)
<0> or frustrating atleast
<1> minDscrm: No. That's not correct.
<0> well.. i figured it wouldnt' be correct... it was my first stab.. my first stab is never correct.. i'm gonna thumb through another book and stop bugging you guys
<1> minDscrm: Codd's Rules, although brief and quick to read, might be a little too much for you to handle. Just read them without necessarily worrying if you understand "why" at this point. Later you may think back to something you saw and it might begin to ring a bell.
<4> Hey, I'm having a problem finding the max id of a table
<4> see my code: http://hashmysql.org/1517
<0> thanks for that site Xgc .. i'll have a read
<4> everything seems to work fine.. but it doesn't insert the n_defect(should be MAX id)... and so it gives an error that it can't be NULL
<2> Xgc: Might I ask your opinion on something?
<1> minDscrm: Just as you have a hard time understanding where to start, it's also not easy for me to know what you're ready to absorb. There are a ton of resources to help you with this. Just ask if you think you need readings in a little different area.
<1> kambei: Sure.
<2> Xgc: I asked a bit earlier, with no response.
<0> thanks Xgc
<1> kambei: One moment. I'll look up. How many minuts ago?
<1> minutes
<2> no
<2> I'll repeat.
<2> I'll rephrase it batter.
<0> sorry for being a smart ***.. i'm just having fun.. and i have a sense of humor about this stuff.. i have to.. i've been working on this since 6am this morning and it's dull as hell.
<1> Ok. That's fine.
<2> Xgc: if I want to store a list of "ingredients", would the proper course of action be to use a set, or multiple booleans?
<2> I understand, roughly, the limitations of both.
<0> ah.. i want to make a recipe database one day also!
<0> i have a million recipes
<1> kambei: Usually, a set (1-N relation) is the proper approach.
<2> Xgc: Can you briefly clue me in as to what makes it proper?
<3> Xgc, Good luck...
<1> kambei: First, when you say multiple booleans, tell me what that means to you.
<2> Okay.
<1> will :)
<2> a set comprised of ('milk','sugar','eggs')
<2> Or a field for each:
<2> milk = true
<2> sugar = true
<2> eggs = true
<3> oh boy
<1> kambei: The bitfield (boolean) approach probably isn't going to scale well if you have to maintain that manually. Let the database decide implementation/storage details.
<2> Well, my inclination, and previous work, has not used booleans.
<2> + in such a manner.
<1> kambei: Both represent sets. Just use the normal table/row/column approach to store atoms.
<1> kambei: That was a good choice. Don't try to outthink the database engine regarding storage details.
<2> Xgc: Right, well, I figured that you guys might have some insight that might have escaped me.
<2> Xgc: Thanks for the input.
<1> kambei: You're welcome.
<4> can anyone take a quick look at my code: http://hashmysql.org/1517 and see if they can see why it's not getting the MAX id?
<0> i'm reading 'mysql' by pual dubois from new riders -- i think it's a great book ; it's from 2000 but i don't think that matters for me being a beginner at the moment.... he does a real nice job at saying things -- he glossed over how to setup a delineated file for loading into tables though ! argh :)
<0> but he's walking me along nicely
<1> kambei: Codd's 12 Rules, which I referred to above, contain rules which state that since [sugar] is considered an atom in your model, it should be stored in a separately addressable cell / column.
<0> what is it..the 12 commandments! nice.. i can't wait to read them
<1> kambei: Your bitfield/boolean approach would violate that fundamental principle.
<0> it appears taht i have to register and login to read these Codd's rules?
<1> minDscrm: One of the links I showed you has that list of 12 rules.
<5> no, just google for Codds rules
<0> http://www.sqlservercentral.com/columnists/fkalis/coddsrules.asp
<1> minDscrm: It's all over the net.
<1> minDscrm: Just google for Codd's 12 Rules
<6> !google codd's 12 rules
<6> !google codd's 12 rules
<7> codd's 12 rules: http://www.itworld.com/nl/db_mgr/05072001/
<0> alphablue.. you were the guy that mentioned the EXIF data.. and how there is no need to store the directory that the image is stored in
<5> minDscrm: i said that's one way you can do it.. but yes
<0> yea... i was trying to explain to kambei what you said.. but i botched it up nicely
<5> hehe
<0> aahh.. 1970 .... nice
<5> not as old as the rules of moses
<5> but good enough
<8> how would you update multiple tables in one command
<5> i don't know. i don't know why you would wanna do such a thing
<0> the older the better.. i feel... if it still relates to the present day -- then what they said back then .... has a lot of meaning and can be expected to still hold true in the future.. time tells all.
<0> i love stuff like this
<6> update table join table on condition set stuff
<8> can you do that with an inssert statement as well?
<1> titosanta: If your engine supports it, just UPDATE table1, table2, ... SET table1.col1='blah', table2.col5='val', ... WHERE ...; -- You can use standard JOIN syntax as well.
<6> I like explicit joins
<1> titosanta: The reason you might want to do that is to update related data that spans multiple related tables.
<1> I also prefer the [JOIN] syntax.
<2> alphablue: If you store the EXIF information, what do you do with the binary data?
<5> you discard it. the images just reside on the file server
Return to
#mysql
or
Go to some related
logs:
#fedora
#css
#osdev
#web
what werw you doing yesterday
#linux
#web
#qemu
Gtk-WARNING **: Unable to locate theme engine in module_path: clearlooks,
#linuxhelp
|
|