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.
Related
This is a fictitious example to try to illustrate some design choices I have...any thoughts or links deeply appreciated.
Imagine we have a MySQL database with a table (call it libTBL) that contains a row for each book in a library.
This table will be updated, by admins, as new books are added.
Users will be able to create a library of such books - that is, a list representing THEIR selected books.
Users can add a personal, private comment to each book and other meta data (when they started reading it, a review etc).
Users can also add their own books, but these books should not appear in the libTBL table.
What are best practices for capturing this user data?
When a user is created, create a row in a new table, with each book in the libTBL represented, so IF the user adds notes or other data we already have a home for it?
Create a new row in a user library table only when they make a note on a specific book?
-- One use case, though, is a user ordering their subset library...which would require a new row for each book they order (or all of them, depending on how ordering was implemented).
Use bookID and userID to query a user table for custom values for a particular book?
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 am building a website of engineering and construction in which I have list of products such as bridge, towers and all are linked. When the user clicks on bridge then its type appears from mysql table on the same page which is in the form of image but the problem is again I want to retrieve the value i.e. its sub-types which are also images. And then when user clicks that image its details will be appeared. Basically its a hierarchy up to 3-4 levels. But don't know how to make relationships between tables.
If the items in your hierarchy can be generalized enough, you could make a single table with the columns: id, parent, information
One entry could be id=Bridge, Parent=Architecture, information=picture_source
You can then make lookups like, show me every entry that has Architecture as its parent and send the list to the client.
Use InnoDB engine for mysql. MyISAM don't support foreign keys (if you are using the default).
you can use:
ALTER TABLE table_name ENGINE=InnoDB;
use parent -child relationships like this,
example:
when clicked on bridge - take data from child 1 table having same fk-key from main table ,
so your all bridge types will appear
Do same for all your sub items
I want to create a site in PHP with cakephp that users can insert product manually.
The problem is for the multilanguage because I can have into my site users from all over the world and the product 'apple' in italian for example is 'mela'.
Consider that I can have many many data!
Then i have some solution for the database:
Create a table products with an id
Create a table product_aliases where I have an id the id of product language and the text(ex. apple)
In this mode users can enter into 'apple', translate ad I insert a new line into product_aliases with same id product different language and different text but same product
Define 5 language and create a table with more fields (title_en, title_it, title_es...) the translation is in the same record
Only one table but restricted language
Create a table products with an id
Create a table for every language that i want for example: prducts_en, products_it where I can store my data with same foreign key to the product but divide from language to make fast query.
Other solution are accepted!!
I never work with large multilanguage database help me and tell me what is the best solution for my database
The first one is the correct solution in general.
It's used in many enterprise applications: a table with an id field for identification of the not multilanguage information (example: unit price for a product) and a table with a row for every combination product/language.
The second one is against every db normalization rule.
The third one is a different derivation of the second one, and if you use an index on the language column in the translated labels table you should not have a great disadvantage in terms of performance.
If you need I will explain better!
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