I am working on an event system that has two tables, EVENTS and EVENT_CREATORS. I have been linking events to creators by placing creator id in the events table as I thought I would only ever have one event creator.
I now need the ability for more than one creator to edit an event. Should I add simply add additional fields to EVENTS table, i.e ec_id, ec_id_2, ec_id_3, etc. Or does it make more sense to add a cross reference table to the database and a separate table for additional creators?
This is those cases, where it would be wise to use a cross reference table. I will explain it step by step. First
Create a new table. Call it "event_reference"
Give the following FIelds: Id, Ref_Id, Creator_ID.
I will omit the need of the EventId, because we are creating a table which is a reference to the event, so event's table will hold the Ref_Id to keep in track of all the references.
Next, Modify the events table and store Ref_ID instead of Creator
In such way, you can fetch all the creators of an events in the normalized way.
You should have 3 tables:
Event (with an ID field)
Creator (with an ID field)
EventCreator (2 fields: eventID and creatorID)
This should pretty much cover every possible relationship between events and creators. You can limit the relationships by creating indexes on the EventCreator table.
The simple say is to just add a cross reference table. This way you don't have to worry about how many creators someone will need in the future.
So, have a table like:
xref_Events_Creators
EventId
CreatorId
Related
I am very new to web Applications and trying to make a simple web application using php and Mysql.
I have created a table named Item having 2 column pen and pencil.
For each user I am inserting values in these two columns.
Suppose In future I got a new Item sharpner from UI.
I want to create a new column automatically in this Item table every time I got a new item from UI.
I am searching for any library or tool using that I will able to do this.
I want to create a new column automatically
No you don't.
You've defined two entities. An instance of an item, and a type of an item. Create a table for each:
item_type
----------
ID
Name
item
----------
ID
ItemTypeID
[other data you're tracking]
The item.ItemTypeID column would be a foreign key to the item_type table.
When a user adds a new "item type", you add a new record to the item_type table. You're then free to add instances of that type of item to the item table.
In the vast majority of cases, dynamically modifying your schema isn't what you want. Define the structure of the data you want to track and build that structure. Then simply add/modify/remove records of that data. Don't re-structure the data itself.
As noted by David there is better design in relational database world. However if your application is essentially requires some sort of dynamic schema, you might consider using Document - oriented database such as MongoDB or Couch.
So my question is very much just a database design question. I'm relatively new to PHP, taking my first database course, and I'm trying to figure out how best to execute my idea.
So I'm building a membership database. Within this database there are "members" and there are "meetings," represented as two separate tables. I'm wondering what might be the best way to add a list of members to a meeting instance, or create a relationship table between the two. For example, would you advise that each member ID (primary key) be added individually (say, via a bunch of text input form fields) when creating a new meeting instance? Or perhaps is there a way to easily have the user upload a CSV or excel file of primary key user id numbers and, from those user number ids, easily create a relationship table?
Hope this is clear- just hoping to get some advice/insight, perhaps I'm not aware of the easiest way... Thanks!
I don't know what are you trying to do in your particular case, but is sounds to me that you should have three tables:
members - you have that one already
meetings - you also have that one already
members_meetings: this one is the table, that will join the two tables. And the required fields in that table should be:
member_id - the id of particular member, points to the id field in your members table
meeting_id - the id of the meeting, this member is attending, points to the id field in the meetings table
Than, if you want to get all members, that are attending meating X, you can just run the following query:
SELECT members.* FROM members_meetings LEFT JOIN members ON members_meetings.member_id = members.id WHERE members_meetings.meeting_id=X
I just would like to know what are the most common approaches to get a table to hold a reference to IDs from multiple tables.
I have a system with modules like customers, suppliers, orders, etc. and I would like to add a "Notes" functionality to all of those modules to be able to add/read notes.
As one customer/supplier/order can have multiple notes, I have chosen the one-to-many relation way and so the notes in their table should refer to the particular item id in a separate column.
But as I will refer to IDs from multiple tables, their IDs will be overlapping and I need a way to say in which particular table to search for that ID.
I don't want to create exact the same notes module for each of my modules and here I could concentrate notes in one table. Those notes differ only in the fact, to which module they belong to.
Shall I
store the particular table name in the notes table? But that name can
change later and the system will break
introduce something like UNIQUE ID or a hash to all of my modules,
which would be unique among different tables and store it's id in
the notes table?
create separate notes table for every module and don't worry about
code/class/table duplication?
Thanks for your ideas!
We do something similar with notes that can be attached to many objects. Each of our objects has a unique class id (we store each type of object in it's own table), and we store the unique class id + specific object id in the notes table.
We then just have to maintain a lookup of unique class id -> table name. By using the unique class id + object id as the key we ensure that the same id in different tables isn't an issue.
I want to create a posting system to a profile. I created a database for storing all users posts each user have a table.
Ihad created another database for storing the comments of each posts. My logic is to create each table in the comments database and store each comment in that.
Is there a logic to link the post and the comments. I thought to use mysql last insert id but it will return last id which will create error because one of the post will not have a table.
Is there any other way?
Another way would be to have a single table for posts, and identify a user post in the table using a userid column. To find all posts by a particular user, simply query by the user's ID. By doing so, you have a single table to manage, and you can do a lookup easily. If you create separate tables for each user, you have to create additional logic to first figure out which table to use. If a user is removed, you delete a table, rather than simply removing some rows from a common table.
The same logic applies to the comments table - add columns for postid',commentid,userid`. Again, a single table contains all the comments. To find comments on a particular post, you would do a simple query such as
select comment_text
from comments_table
where postid = ?
The whole purpose of using MySQL is to leverage relationships between entities, i.e. a user owns posts, a post is linked to comments.
If you do not want to use a relational schema like this, take a look at NoSQL DBs.
You have a couple options here:
Add a user_id column to your posts table, and a post_id, and user_id column to your comments table. You can then setup foreign keys with one-to-many relationships.
Only use a single table that has (in addition to your existing) a user_id, and type column. Type will define comment/post/etc. This can be defined with intermediary tables as a number mapped to a CONST, string, or any other way that you see fit (intermediary best option imho).
Vary the above example and use 2 intermediary tables to match users to posts and comments to posts (possibly also users to comments).
I am trying to get my head around an issue relating to database logic.
I have a system that is to allow the user to create an event, performances and multiple different ticket types for a given event. These will then be added to the database with prices relating to the ticket types for a given event (the ticket types can be reused for other events and there is no set number of types for each event) and then a customer will go onto the site, select one of the events, performances and will then have listed for them to choose from the different ticket types with prices.
At this point I have a table for events which is using a series to store the ticket ids which are stored in a separate table and yet another table which stores the prices. The use of the series is ridiculous as it tends to crap out on me and either fails to work (as mysql doesn't handle the code properly) or it is incredibly limiting on what can be done with the info Has anyone any better idea how I might achieve this result?
example of an event:
event name: 'event 1'
performance: '23/03/13 (12:30)'
ticket types: Adult (€20), Student (€15), Special (€10), etc
the person setting up the event can create any ticket types they want or use existing ones in the system and just have a price set for this particular event.
If I understand you correctly, I believe what you are doing is most likely the best way to do it.
A user can create multiple events, each of which can have a variety of tickets. Tickets are not specific to an event (can be used on multiple events), and thus the price can not be stored with the ticket information.
Therefore, what you want to do is have these tables:
events - Stores information on the event
tickets - Stores information on the ticket
*events_tickets* - a join table for events and tickets (As it is a many to many relationship)
The events_tickets table would have columns like so:
primary id, event_id (Foreign Key), ticket_id (Foreign Key), price
Hope that helps.
table Event: Id_Event, Ds_Event, Dt_Event, Id_Venue
table Ticket_Type: Id_Ticket_Type, Ds_Ticket_Type, Ic_Ticket_Type_Is_Custom (boolean)
table Event_Ticket_Type_Price: Id_Event, Id_Ticket_Type, Nr_Ticket_Price
table Venue: Id_Venue, Ds_Venue, Ds_Venue_Address