Ferreira, [I have posted this back to the list. There are many others who will be able to help - some from Portugal. Also I have noticed questions and comments from many people working on collections/libraries of CDs, videos, books, etc]
> Thack for all that knowleg... ( wisdonw ) > pardon my englihs =please do not feel it necessary to apologise - your ability to write in English is much better than mine in Portugese! > in this case, and before the big databank, i am tring to build a DB to > organise my cds. > I have 6 tables. > Table Principal has: > a "id" and for exmple "tipo" ( type). > > Table Tipo (Type ) has: > a "idT" and Descrição ( description). > > my question: > in table Principal e call the column tipo has "idT" and i have a relation? > or i just call it "Tipo" and manualy work on it so it can get the values i > have on the other table ? > > ( I am a self-teacher all i know i read it somewere sorry if the questions > are dull ) =it's trying to keep the answers from sounding dull, that is challenging! =yes I think you have the correct answer. When you define the two tables (using a CREATE statement) there is no need to specify/hard-code, some linkage between them. When you populate the tables with data, the data-values will make apparent/show the linkages (field(s) to field(s) and thus row(s) to row(s)) =the two tables Principal and Tipo are logically related - logic demands that there be no entry in Principal.tipo that does not have a corresponding entry in the Tipo table. (this is called "data integrity"). So we can write a SELECT (or other) command to only work with data within this correspondence/relationship, eg ... WHERE Principal.tipo = Tipo.idT =from there (for two examples), we can ask to see only CDs of a certain type, or we can ask for a list of all the CDs purchased during 1999 (assuming relevant data columns are available) organised into groups by type/tipo - simply by adding more conditions/constraints into the WHERE clause (etc). =thus it is not when you CREATE the tables that the linkage is specified, but each query that you run against the tables can/must specify the linkage (and therefore you can relate different tables at different times, even in different ways at different times). Relationships are/can be 'dynamic', rather than constant/'fixed' at table creation time. =if you want to demand a data integrity feature, whilst it is not available in native-MySQL, it is available in one of the add-on components. > Thancks in advance. =my pleasure - and don't hesitate to request clarification if my choice of English words is not readily understandable. =dn > > I am playing hard with mysql, cause my ultimate objective is to make a big > > databank for a game. > > > > I notice that i cant find a way to make relations beteen tables. > > Must i do it also with PHP ? > > > Just to confuse you, the mathematical jargon for table is "relation"... > > May I suggest that you search the web for some tutorials on the use of SQL > in general/MySQL in particular - it > will help your playing, and ultimately your game. > > There are some RDBMS-es that implement SQL to the point of apparently > setting up a construct that links tables - > foreign key based data integrity being the first example that springs to > (my) mind. However relational logic > suggests that the way to set up a linkage between tables is to show this in > dynamic logic - your SQL statement, > eg > > SELECT * > FROM tbl1, tbl2 > WHERE tbl1.PrimaryKey = tbl2.ForeignKey; > > will produce a result-row for every intersection 'match' between the two > tables. > > One of the MAJOR advances of relational databases over their predecessors > was this move 'away' from structural > 'connections'. However these have been maintained as 'features' by some, > usually to promote speed/efficiency. > Perhaps this is a major interest for you/gaming - but in which case, you > will find that indexed-file systems > will likely be a better/faster/smaller option. (?) > > An original objective, and one well worth bearing in mind today, is that > relational technology allows one to > establish a 'relationship' between items of data today, that was not > anticipated/designed into the system when > it was first built n-years ago. Flexibility! > > Regards, > =dn > > --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
