I am trying to learn magento framework. But it is hard to understand the database structure. So I am looking for a document that describe what each table exactly do and explain each column in that table. I have searched on google but all I found was magento database structure without any describes (table and column) Magento Database Diagram
ex:
the field converted_at in sales_flat_quote table. I have no idea what this field do.
What I looking for is like this topic excellencemagentoblog.com: Magento EAV Database Structure but it is only describe eav table
ps: so sorry because my bad english
Below link would solve all you queries related to Database Structure :
http://excellencemagentoblog.com/blog/2011/09/07/magento-eav-database-structure/
Below 2 links would show you the Database Diagram :
http://inchoo.net/wp-content/uploads/2010/09/MAGENTO_v1.3.2.4-Database_Diagram.pdf
Its better if you go through whole Magento Knowledge Base Documents available first and then go for understanding the Database.
EAV tables are used to give us the flexibility of adding unlimited Attributes for Products, Categories, Customers etc at any point of project even without bothering to update the database.
You need to understand Stores, Eav Attribute Set, Product Attributes, Website as all of this values are stored in Tables to differ the values.
Related
Writing (.net) a simple app that logs whether a user has access to a program or not. Cannot figure out the best way to structure the DB/tables.
Interface will have two listboxes with buttons in between to add/remove items. What is the best way to layout the tables for easy querying?
Thanks (not a DB guy obviously!)
I recommend reading up on basic database design principles if you plan to continue working in this area.
https://en.wikipedia.org/wiki/Database_design
http://www.tomjewett.com/dbdesign/dbdesign.php?page=manymany.php
https://msdn.microsoft.com/en-us/library/office/aa200276(v=office.11).aspx
If I understand your question then a table of programs, a table of users, and a "many to many" table where each row contains an id from the user table and an id from the programs table if the user has access should suffice.
I'm working on a project to make a digital form of this paper
this paper (can't post image)
and the data will displayed on a Web in a simple table view. There will be NO altering, deleting, updating. It's just displaying (via SELECT * of course) the data inputted.
The data will be inserted via android app and stored in a single table which has 30 columns in mysql.
and the question is, is it a good idea if i use a single table? because i think there will be no complex operation in the sql.
and the other question is, am i violating some rules for this method?
I need your opinion. thanks.
It's totally ok to use only one table, if that suits your needs. What you can do to make the database a little bit 'smarter' is add new tables for attributes in your paper that will be repeated. So, for example, the Soil Type could be another table where there are two columns, ID and Description, and you will use it as a foreign key in each record in the main table. You need this if you want your database to be in 3NF.
To sum up, yes you can have one table if that's all you need. However, adding more tables might help save some space and make your database more flexible. It's up to you to decide! :)
Being new to relational database design, I am trying to clarify one piece of information to properly design this database. Although I am using Filemaker as the platform, I believe this is a universal question.
Using the logic of ideally having all one to many relationships, and using separate tables or join tables to solve these.
I have a database with multiple products, made by multiple brands, in multiple product categories. I also want this to be as scale-able as possible when it comes to reporting, being able to slice and dice the data in as many ways as possible since the needs of the users are constantly changing.
So when I ask the question "Does each Brand have multiple products" I get a yes, and "Does each product have multiple brands" the answer is no. So this is a one to many relationship, but it also seems that a self-join table might give me everything that I need.
This methodology also seems to go down a rabbit hole for other "product related" information such as product category, each product is tied to one product category, but only one product category is related to a product.
So I see 2 possibilities, make three tables and join them with primary and foreign keys, one for Brand, one for Product Category, and one for Products.
Or the second possibility is to create one table that has the brand and product category and product info all in one table (since they are all product related) and simply do self-joins and other query based tables to give me the future reporting requirements that will be changing over time.
I am looking for input from experiences that might point me in the right direction.
Thanks in advance!
Could you ever want to store additional information about a brand (company URL, phone number, etc.) or about a product category (description, etc.)?
If the answer is yes, you definitely want to use three tables. If you don't, you'll be repeating all that information for every single item that belongs to the same brand or same category.
If the answer is no, there is still an advantage to using three tables - it will prevent typos or other spelling inconsistencies from getting into your database. For example, it would prevent you from writing a brand as "Coca Cola" for some items and as "Coca-Cola" for other items. These inconsistencies get harder and harder to find and correct as your database grows. By having each brand only listed once in it's own table, it will always be written the same way.
The disadvantage of multiple tables is the SQL for your queries is more complicated. There's definitely a tradeoff, but when in doubt, normalize into multiple tables. You'll learn when it's better to de-normalize with more experience.
I am not sure where do you see a room for a self-join here. It seems to me you are saying: I have a table of products; each product has one brand and one (?) category. If that's the case then you need either three tables:
Brands -< Products >- Categories
or - in Filemaker only - you can replace either or both the Brands and the Categories tables with a value list (assuming you won't be renaming brands/categories and at the expense of some reporting capabilities). So really it depends on what type of information you want to get out in the end.
If you truly want your solution to be scalable you need to parse and partition your data now. Otherwise you will be faced with the re-structuring of the solution down the road when the solution grows in size. You will also be faced with parsing and relocating the data to new tables. Since you've also included the SQL and MySQL tags if you plan on connecting Filemaker to an external data source then you will definitely need to up your game structurally.
Building everything in one table is essentially using Filemaker to do Excel work and it won't cut it if you are connecting to SQL, MySQL, etc.
Self join tables are a great tool. However, they should really only be used for calculating small data points and should not be used as pivot points or foundations for your reporting features. It can grow out of control as time goes on and you need to keep your backend clean.
Use summary and sub-summary reporting features to slice product based data.
For retail and general product management solutions, whether it's Filemaker/SQL/or whatever the "Brand" or "Vendor" is it's own table. Then you would have a "Products" table (the match key being the "Brand ID").
The "Product Category" field should be a field in the "Products" table. You can manage the category values by building a standard value list or building a value list based on a "Product Category" table. The second scenario is better for long term administration.
I am new to SQL, I am trying to "map" data from several tables in ONE database to create ONE table with relational information. For example, I am trying to take data from my tables ps3_productcategories, ps3_categories and "map"/"merge" to the ps3_products table, The previous tables contains all the "category information" needed to map to "correct products".
I am trying to "MAP" the productID to the "correct"=> categoryID=> categoryName=> categoryParent etc.....
Any help would be appreciated
I suggest you look into views, it may be what you are looking for, although they do not create this in another database they do allow to create virtual tables from existing data.
A database View is known as a "virtual table" which allows you to query the data in it.
See the MySql manpage on views..
And here is a small tutorial on the subject.
If you really need this in a seperate database, you can easily create a view and export the results of that, and import it in other database.
I need to create an ERD for our DB system. As it happens, there are lots and lots of tables, and no one really understands much of it. What's more, the same DB has tables for different applications, so not all tables are relevant to my application. I need an ERD for only my application's tables.
I tried creating ERD from MySQL workbench. It allows me to select a subset of the tables to put on an ERD, but that's the problem: I don't know which tables to select ( One of the reasons to build the diagram in the first place :-) ).
What I do know are some of the 'main' tables involved. What I'm looking for is this: I tell the tool some 5-10 of these main tables I'm interested in, and the tool automatically picks up all the tables that are linked to these tables, and creates the ERD for them.
Any pointers?
Otherwise, I'll have to live with building my list of tables manaully, one by one...
http://www.fabforce.net/ has a nice tool called DBDesigner, I have used this in the past for some reverse engineering on a datamodel.