this is a simple question.
With PHP and MySQL, I'm trying to build a bug reporting application.
Currently, the user can post bugs and a list of bugs is portrayed to the technician/administrator.
How do I make it so that many technician or administrators can reply to the report (thread?)
As in both mysql table layout and PHP coding?
The current MySQL table has layout of:
id (Bug ID)
by (person reporting it)
title (Report Title)
content (Contents of Report)
datetime (Date/Time of report)
application (Application/page where problems happens)
priority (Priority)
assigned (Assigned To)
status (Status of report/bug)
So no response column yet, but how do I achieve multiple post/responses with PHP and MySQLi?
Thanks
This would be a many-to-one relationship. You can either have:
response table
id (response id)
bugid (bug id)
columns related to the response
or
response table
id (response id)
columns related to the response
with
bugresponse table
responseid (response id)
bugid (bug id)
columns related to the bug-response relationship
where the second design can also handle many-to-many relationship (unlikely to be necessary in this case) and can also has some other benefits depending on your requirements.
You make another table with the responses. For instance with the layout
id (Response Id),
responseTo (id of the Bug this is a response to),
by (person responding),
content (Contents of Response)
Where responeTo is the crucial field. Then when you want to view all the response to a bug you just select from the response table where responseTo = currentBugId.
What you usually do is you create a separate table for the responses. In that table you have one field that "points" to the first table. It could look like this:
TABLE responses
id (Unique id)
bug_id ("Pointer" to which bug this response "belongs to")
body (Contents of response)
This way you can have many responses which all point back to one bug, and thus you have virtually created an "ownership" or "relation". It is customary to call a relation like the one above a "one to many" if we pretend we're in the bugs table, looking out. (And a "many to one" of we're in the responses table, looking back at the bugs table.)
Then, in PHP, when you want to retrieve all the responses belonging to a bug, you do something like this: (pseudo code)
$bug = SELECT * FROM bugs WHERE id = $some_id
$resps = SELECT * FROM responses WHERE bug_id = $bug['id'] ORDER BY created_at
Voilá! Now you have the bug and all of its responses, ordered by creation date. When you insert new responses you need to set bug_id to the appropriate value, of course.
Cheers!
Related
I've the following model Order.
Any order can have such status as new, in work, being delivered, on storage, executed, cancelled.
I found the following code in the model:
As for now every order has number what identifies its status.
If I started the project from scratch I would rather create a separate table with the name let's say order_status and insert primary keys from it into Order table.
What approach is more preferred and why?
Thanks
you can take a column named as status and set the number what ever it is like 1,2,3,4,5,this approach is more convenient than creating a new relation ship table because it uses extra join to retrieve status,it will be useful if order have multiple status at the same time otherwise you can update status of that order in same table.
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 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
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
I'm building a website that constructs both site-wide and user-specific activity feeds. I hope that you can see the structure below and share you insight as to whether my solution is doing the job. This is complicated by the fact that I have multiple types of users that right now are not stored in one master table. This is because the types of users are quite different and constructing multiple different tables for user meta-data would I think be too much trouble. In addition, there are multiple types of content that can be acted upon, and multiple types of activity (following, submitting, commenting, etc.).
Constructing a site-wide activity feed is simple because everything is logged to the main feed table and I just build out a list. I have a master feed table in MySQL that simple logs:
type of activity;
type of target entity;
id of target entity;
type of source entity (i.e., user or organization);
id of source entity.
(This is just a big reference table that points the script generating the feed to the appropriate table(s) for each feed entry).
In generating the user-specific feed, I'm trying to figure out some way to join the relationship table with the feed table, and using that to parse results. I have a relationships table, comprised of 'following' relationships, that is similar to the feed table. It is simpler though b/c only one type of user is allowed to follow other content types/users.
user/source id;
type of target entity;
id of target entity.
Columns 2 & 3 in the feed and follow table are the same, and I have been trying to use various JOIN methodologies to match them up, and then limit them by any relationships in the follow table that the user has. This is has not been very successful.
The basic query I am using is:
SELECT *
FROM (`feed` as fe) LEFT OUTER JOIN `follow` as fo
ON `fe`.`feed_target_type` = `fo`.`follow_e_type`
AND fo.follow_e_id = fe.feed_target_id
WHERE `fo`.`follow_u_id` = 1 OR fe.feed_e_id = 1
AND fe.feed_e_type = 'user'
ORDER BY `fe`.`feed_timestamp` desc LIMIT 10
This query also attempts to grab any content that the user has created (which data is logged in the feed table) that the user is, in effect, following by default.
This query seems to work, but it took me sometime to get to it and am pretty sure I'm missing a more elegant solution. Any ideas?
The first site I made with an activity feed had a notifications table where activities were logged, and then friends actions were pulled from that. However a few months down the line this hit millions of records.
The solution I am programming now pulls latest "friends" activities from separate tables and then orders by date. The query is at home, can post the example later if interested?