I'm trying to build a searchable database of acronyms and their definitions that are specific to a certain industry. It has been years since I've done any real programming, so I'm a little behind the learning curve.
I'm writing the code in PHP, and I'm using MySQL as the database. If this can be done easier in Postgres, I'm not opposed to switching DBs, but I can't use Oracle or any other commercial system.
So here's the question:
I'd like to set it up so that each acronym can: (1) apply to 1, multiple, or no specific organizations; (2) have 1 or more associated definitions.
The complexity--at least in my mind :D--comes in that it is conceivable that some organizations might have a single acronym with multiple definitions that all relate to that one organization. At the same time, the acronym may have 1 or more definitions that relate to OTHER organizations as well.
Am I over complicating this?
I'd like to better understand how to setup the table structure and relationships in MySQL--what fields and relationships would be in each table.
A SQL statement would be helpful if anyone feels so inclined, but I'm hoping to at least get a solid grasp on the database schema so I can get the tables created and some sample data imported.
Many, many thanks to all...
Dan
The solution should contain 4 tables: Acronyms, Definitions, Organizations, and AcronymOrganization.
Acronym(id, acronym, definition_id)
Definitions(id, definition)
Organizations(id, organization)
AcronymOrganization(id, acronym_id, organization_id)
If I understand your question, you can use three separate tables. First, have the table of acronyms/definitions, then have a table of Organizations. Finally, have an AcronymOrganization table, that just references a key from the acronym table, and a key from the organization table. This way, you can have as many acronyms for an organization as you please.
After you set up the database, you need to use a couple inner joins to join the three tables, collecting only the acronyms for the appropriate organization ID.
I'd just create an acronym table, an organization table, and a definition table. Put two foreign keys in the definition table: one for the entry in the acronym table, and the other for the entry in the organization table.
If you want to have a n:m relationship between tableA and tableB, then you need a third table.
table A. Fields : ID,name
table B. Fields : ID,name
table AB. Fields : A,B (A is a reference to A.ID, B is a reference to B.ID)
[TABLEA]1-----*[TABLE_AB]*-----1[TABLEB]
Example
Contents of table a:
ID Name
1 John
2 Mary
3 Piet
Contents of Table b:
ID Name
1 Microsoft
2 Google
3 Philips
Contents of Table ab:
ID Name
1 2
1 3
2 2
3 1
3 3
Then select everything like this:
select a.name,b.name
from a,b,ab
where a.id=ab.a and b.id=ab.b
Result:
a.name b.name
John Google
John Philips
Mary Google
Piet Microsoft
Piet Philips
Related
I'm currently working on an app backend (business directory). Main "actor" is an "Entry", which will have:
- main category
- subcategory
- tags (instead of unlimited sub-levels of division)
I'm pretty new to OOP but I still want to use it here. The database is MySql and I'll be using PDO.
In an attempt to figure out what database table structure should I use in order to support the above classification of entries, I was thinking about a solution that Wordpress uses - establish relationship between an entry and cats/subcats/tags through several tables (terms, taxonomies, relationships). What keeps me from this solution at the moment is the fact that each relationship of any kind is represented by a row in the relationships table. Given 50,000 entries I would have, attaching to a particular entry: main cat, subcat and up to 15 tags might slow down the app (or I am wrong)?
I then learned a bit about Table Data Gateway which seemed an excellent solution because I liked the idea of having one table per a class but then I read there is virtually no way of successful combating the impedence missmatch between the OOP and relational-mapping.
Are there any other approaches that you may see fit for this situation? I think I will be going with:
tblentry
tblcategory
tblsubcategory
tbltag
structure. Relationships would be based on the parent IDs but I+'m wondering is that enough? Can I be using foreign key and cascade delete options here (that is something I am not too familiar with and it seems to me as a more intuitive way of having relationships between the elements in tables)?
having a table where you store the relationship between your table is a good idea, and through indexes and careful thinking you can achieve very fast results.
since each entry must represent a different kind of link between two entities (subcategory to main entry, tag to subcategory) you need at least (and at the very most) three fields:
id1 (or the unique id of the first entity)
linkid (linking to a fourth table where each link is described)
id2 (or the unique id of the second entity)
those three fields can and should be indexed.
now the fourth table to achieve this kind of many-to-many relationship will describe the nature of the link. since many different type of relationship will exist in the table, you can't keep what the type is (child of, tag of, parent of) in the same table.
that fourth table (reference) could look like this:
id nature table1 table2
1 parent of entry tags
2 tag of tags entry
the table 1 field tells you which table the first id refers to, likewise with table2
the id is the number between the two fields in your relationship table. only the id field should be indexed. the nature field is more for the human reader then for joining tables or organizing data
I use MySQL and trying to write a PHP script for my school project.
There is one table named lessons contains this columns:
-id
-lessonid.
-studentid
I also have two different tables for notes and announcements
announcements and notes tables contains these columns:
-id
-lessonid
-content
-createdtime
I need to order both announcements and notes from latest to oldest by createdtime but also need to show all lessons a student takes.
For example: A students takes maths and physics lessons. I need to display him/her both notes and announcements for both of physics and maths and all items should be ordered by date. (like a timeline.) And of course I will not show him/her the notes and announcements for chemistry lesson. Also it will be good if I can say it is note or announcement on the list.
Can you help me to write SQL and PHP code for that?
Thanks.
EDIT: This is where I have stuck:
I have combined two tables and ordered them by date. But can't combine them with the lessons a student take.
SELECT title, created, lessonid FROM (SELECT title, created, lessonid FROM notes UNION SELECT title, created, lessonid FROM announcements) as a ORDER BY created DESC
First of all, thanks for letting us know that this is for a school project - therefore I won't give you the answer. If it is in the project then your teacher should have given you the concepts to come up with a solution.
Your question is well put together and I can see how to solve it but ... It's your project so you need to have a crack at it and post what you come up with.
I will give you some hints to get you started.
You need a query to combine the announcements and notes table. Then you need to group the data by the lesson and join that to the students. This is all basic SQL.
Good luck. Post what you come up with.
I'll also, follow fellow posters advice, and not do the legwork for you. but won't let you go empty handed, so will give you the concept.
there is a thing called third normal form, we decide how many tables according to that concept, so if its a big database then separate table for first name and separate for last name, as many people share those among themselves, so saves space and redundancy etc. so one table for person has personid as primary, and has lastname foreign key to refer to last name table , we generally name it lastNameRef, similarly firstNameRef. so now, each person has lot of classes, and each class has lot of persons(students) in it. so this is a many-many relation - we create a allreference table to solve this many to many problem. so there is one table for classes which has class id as primary key, so now u create a all reference table which a recordId as primarykey, (just for namesake) and personRef(refers to personId in person table) and classref(refers to classId in class table) if one person has two classes, another entry with same personId but different class Id, at the end, you can query the name of person from person table, and name of class from class table and create join on their foreign keys but use all three tables, result is (JOHN MATH, JOHN SCIENCE) etc, same way you display all notes for john searching name in person table, and subject in class table,and notes in notes table
Let's say I have 10 books, each book has assigned some categories (ex. :php, programming, cooking, cookies etc).
After storing this data in a DB I want to search the books that match some categories, and also output the matched categories for each pair of books.
What would be the best approach for a fast and easy to code search:
1) Make a column with all categories for each book, the book rows would be unique (categs separated by comma in each row ) -> denormalisation from 1NF
2) Make a column with only 1 category in each row and multiple rows per book
I think it is easier for other queries if I store the categories 1 by 1 (method 2), but harder for that specific type of search. Is this correct?
I am using PHP and MySQL.
PPS : I know multi relational design, I prefer not joining every time the tables. I'm using different connection for some tables but that's not the problem. I'm asking what's the best approach for a db design for this type of search: a user type cooking, cookies, potatoes and I want to output pairs of books that have 1,2 more or all matched categs. I'm looking for a fast query, or php matching technique for this thing... Tell me your pint of view. Hope I'm understood
Use method 2 -- multiple rows per book, storing one category per row. It's the only way to make searching for a given category easy.
This design avoids repeating groups within a column, so it's good for First Normal Form.
But it's not just an academic exercise, it's a practical design that is good for all sorts of things. See my answer to Is storing a comma separated list in a database column really that bad?
What you want to do is have one table for books, one table for categories, and one table for connecting books and categories. Something like this:
books
book_id | title | etc
categories
category_id | title | etc
book_categories
book_id | category_id
This is called a many-to-many relationship. You should probably google it to learn more.
This relationship is a Many-To-Many (a book can have multiple categories and a category can be used in several books).
Then we have the following:
Got it?
=]
I would recommend approach number 2. This is because approach 1 requires a full text search of the category column.
You may have some success by splitting it up into two tables: One table has one line per book and a unique id (call the table books), and the other has one line per book per category and references the book id from the first table (call the table bookcategories). Then if you only need book data you use table books, where if you need categories you join both tables.
I have two tables that look as Follows:
Person (Table Name)
Name1/Phone1/Email1/Address1/Organization1/Notes1 (Fields)
Organization (Table Name)
Organization1/Phone2/Email2/Address2/Web2/Notes2 (Fields)
Organization1 is the only field in common between the two tables.
When I display data on a person, I want to also check and see if there is data on their organization and display it as well if it exists. I'm using PHP to interface with mySQL.
You need to JOIN the tables.
SELECT * FROM Person LEFT JOIN Organization ON Person.Organization = Organization.Name;
This assumes the relationship is the Organization Name. I've done a LEFT JOIN since you said if exists. Check out this tutorial for more detail on joining tables.
Note: I agree and would recommend making your database more relational by adding Primary Keys and using them as Foreign Keys in your other tables.
This post is an explanation of relations, not code for you to use. If you want that, look elsewhere
Well, connections between tables are called relations. There are 3 types of relations.
1) One -> One - This type of relation means 1 row is related to 1 other row in a different table
2) One -> Many - This type of relation means 1 row is related to a variable number of rows in a different table.
An example may be A folder can have multiple files, but a file can't have multiple folders. So in this case the 1 would be the folder, and the many would be the files.
3) Many -> Many - This type of relation means many rows can relate to many other rows.
An example may be labels. You can label many things the same name (desk appliance for example), and each thing can have multiple labels (a lamp can have both desk appliance & light labels).
.
So now that you know the different relations, we will go into your question. The relation you are looking at is a one to many, one corporation can have many people, but a person can only have one corporation. I suppose a person could work for multiple people, but that is much more complex (so we'll skip it).
One to many relations are by far the most common, and are pretty easy to do. This is where joins come in (left, right, and inner joins). Tizag has an excellent tutorial on joins here: http://www.tizag.com/sqlTutorial/sqljoin.php.
Hope that helps.
You should use a foreign key, but you need to use the InnoDB storage engine (MyISAM does not support foreign keys yet).
Make your tables look something like this:
Person_ID, Name, Phone, Email, Address, Organisation_ID, Notes (or if you have multiple notes, create a seperate table that maps person_id to a note).
Organisation_ID, Name, Phone, Email, Address, Web, Notes.
Select your person, then if Organisation_ID exists, select the Organisation where Organisation_ID equals the ID you obtained from the person row.
I'm modelling an ontology in SQL using a tree to indicate relations between concepts.
My problem is how to disambiguate concepts in a graph/tree without replicating concepts.
Eg. I have the concept of courses: "karate", "sailing" (lessons one can take from instructors) and places: "gym", "boat club" where these courses can be taken. In the graph it will be:
gym boat club
has has
courses
of of
karate sailing
How can I model this graph to avoid boat club having karate courses and without duplicating the concept of courses?
Thanks!
I would turn the whole data architecture around and think about this as a graph. Have a table for all the concepts (nodes) - gym, boat club, courses, karate, sailing - and another table to create the links (vertices) between them. That table looks something like:
Links
from (concept foreign key)
to (concept foreign key)
link_type (has/of/etc)
It may take a lot more SQL to build up all your information in memory, but this schema will handle these relationships simply.
The table that contains the data Karate and Sailing would contain the primary keys for the other two tables as foreign keys. This would allow for you to have as many of each data type as you like while still being able to traverse the tables to get your information.