how to create query for below table [duplicate] - mysql

This question already has answers here:
Is storing a delimited list in a database column really that bad?
(10 answers)
Closed 3 years ago.
This is the table of database
**
id products free_pro_id
1 laptop 2
2 pen-drive -
3 hard-disk 2,4
4 mouse 3
i am just wondering how to create query for below output
product free_id_pro**
laptop pen-drive
hard-disk pen-drive,mouse
mouse hard-disk

I understand your problem. But your table implementation is not correct.
First, you have to learn about Database Normalization.
Please refer to this link
https://www.studytonight.com/dbms/database-normalization.php
You can have a table for products and another table for promotions.
Table Products
In this table you can have the prodId and the prodName
prodId-------prodName
1--------------laptop
2--------------pen_drive
3--------------hard_disk
4--------------mouse
Table Promotion
In this table, you can store what are the free products you are giving when user buys a product.
promoId--prodId----freeProdId
1-------------1------------2
2-------------3------------2
3-------------3------------4
4-------------4------------3
If you want to get the free products given for laptop you can do the following query
SELECT freeProdId from Promotion where prodId = 1;
I have given a very simple query to give you a basic understanding. You can modify the query, play around with it and do many things. (Ex. Get the prodName instead of the id)

This is the table of database arrange this type of product table in database
id ----- products ----- free_pro_id
1 ------- laptop --------- 2
2 ------- pen-drive-------- -
3 ------ hard-disk ------- 2
3 ------ hard-disk ------- 4
4 ------- mouse ---------- 3
This is the query to get output of above table
SELECT foo.products ,product.products FROM product foo inner join product on foo.id=product.free_pro_id

Related

How to design MySQL Table Structure for search optimization [duplicate]

This question already has answers here:
Is storing a delimited list in a database column really that bad?
(10 answers)
Closed 2 years ago.
Hello to Folks out there,
I need some suggestion on How to design MySQL Table Structure for search optimization.
I am creating a Real estate website. In that I have property table and all its associated tables.
I can design my table for saving these records in two ways.
I have amenity master table
id property_name
----------------
1 Property A
2 Property B
3 Property C
Approach 1
Property Table
id property_name
----------------
1 Property A
2 Property B
3 Property C
Property_Amenities table
id p_id amenity_id
------------------------
1 1 1
2 1 2
3 1 3
4 1 4
5 2 1
6 2 1
Approach 2
Property Table
id property_name amenity_id
----------------------------
1 Property A 1,2,3,4,5
2 Property B 1,4,7,9,12
3 Property C 3,4,7,8,9,10
Approach 1 Query : I can join tables and get the all the amenities name for a particular property. Add the required index for optimization. For A property there will be 20 amenities on averages. Suppose I have 100K property records then to get amenities for particular property, MySQL query will search in 2 millions records of Property_Amenities table.
Approach 2 Query : I can search using FIND_IN_SET or IN MySQL operator. But I was going through this search topic and it seems that this approach will be much resource intensive and cost more for same amount of data i.e 100k property records.
Any suggestion will be appropriated. What your thought on this scenario or any other approach I should follow.
Use the first approach. Period. The second is wrong, wrong, wrong. Here are some reasons:
A SQL string should not be used to store multiple values.
Integers should be stored using the proper type.
Foreign key relationships should be declared.
SQL has very poor string handling methods.
SQL has a great way to store lists; it is called a "table" not a "string".

MySQL fixed allowed combinations from multiple tables

I am designing a database to organize materials for 3D production.
Materials are named like 1_Fabric_01_Textile_001_BlueJeans_Denim and 2_Metal_02_BrushedMetal_002_ChromeBrushed_Chrome, etc
So, I need a materials table, which basically has information on material name (last value, look above) and a combination of type and subvariant. Each type has allowed variants like 1_Fabric has 01_Textile, 02_Leather, 2_Metal has 01_Metal, 02_BrushedMetal and so on.
Now making all combinations would not be difficult (i.e., being able to choose every possible subvariant for every material type), but I want to limit the combinations to only allowed combinations, so users cannot choose invalid combinations (like 1_Fabric_01Metal or 2_Metal_01Textile).
Any ideas?
In order to generate those kind of name
1_Fabric_01_Textile
2_Metal_02_BrushedMetal
Based on the followin tables
Type
----------
Id Name
-- ------
1 1_Fabric
2 2_Metal
SubType
------------
Id Name
-- ------
1 01_Textile
2 02_Leather
3 01_Metal
4 02_BrushedMetal
And keeping rules on what types can relate to subtypes
You ill need a relational table like:
Type_SubType
-----------------
TypeId SubTypeId
------ ---------
1 1
1 2
2 3
2 4
and if you need more levels of subtypes you can add more tables
1_Fabric_01_Textile_001_BlueJeans_Denim
2_Metal_02_BrushedMetal_002_ChromeBrushed_Chrome
SubSubType
--------------
Id Name
-- ----------
1 001_BlueJeans_Denim
2 002_ChromeBrushed_Chrome
Type_SubType_SubSubType
-------------------------
TypeId SubTypeId SubSubType
------ --------- ----------
1 1 1
2 3 2
Now the trick part is to do a better normalization for the third level relation. It can be achieved if you add a identity column to the first relational table
So instead you can use this example:
Type_SubType
---------------------
Id TypeId SubTypeId
-- ------ ---------
1 1 1
2 1 2
3 2 3
4 2 4
and relating it to the second relational table
Type_SubType_SubSubType
-------------------------
Type_SubTypeId SubSubType
-------------- ----------
1 1
3 2
to retrieve only the possible matches is trivial
select * from type tp
join Type_SubType tp_sb on tp_sb.TypeId = tp.Id
join SubType sb on sb.Id = yb_sb.SubTypeId
or just (if you already selected a type and put it in the variable #TypeId)
Select * from SubType sb
join Type_SubType tp_sb on tp_sb.SubTypeId = sb.Id
where tp_sb.TypeId = #TypeId
and so on for SubSubTypes
note: this solutions only covers a fixed (or maxed) number of sub-sub. To get a total dynamic level of abstractions you ill need a recursive FK. Not something like rocket science but if you still the basics on SQL try stick with the most simple example.

MySql - Update first empty column found

I have a table in Mysql that looks like this:
Name Slot_1 Slot_2 Slot_3
------ ------ ------ --------
MyName MyItem
MyName2
And I have this app with an interface to buy some products. When the client "MyName" buy something in the app, it would store it on "Slot_2" because "Slot_1" is already used; On the other hand, if MyName2 buys the same product, it would be stored on Slot_1 because it's the first free slot found. I searched through several links, but all I found was how to update the first empty row found, and not the column.
Note: The app is made in VB.net, so if you think it would be better to do this app-level, feel free to comment.
Note 2: This is the best db-design I found to do this "inventory". If you think there is a better way to do it, please point me to it.
That is really a bad design. I really suggest to read something basic on building relational databases.
Said that the only correct approach is to have at least three tables
The first table contains the customer informations
IDCustomer Name Address City
---------- ------ ------ --------
1 Steve XXXX YYYY
2 Andre KKKK ZZZZ
The second table contains the Items that can be sold
IDItem Item Price
---------- ------ ------
1 Apple 1
2 Orange 2
The third table links the Customers with the Items sold
IDItem IDCustomer Quantity
------- ----------- ---------
1 1 5
2 2 10
1 2 3
Also if you want to limit the items sold to a customer to only three, that is a business rule that should not be enforced by a database design like that.

Advice on linking product codes to a product in a MySQL database

I need some advice of how to setup my tables I currently have a product table and a product codes table.
In the codes table I have an id and a title such as:
1 567902
2 345789
3 345678
there can be many items in this table.
In my product table I have the usual product id,title, etc but also a code id column that I'm currently storing a comma separate list of ids for any codes the product needs to reference.
in that column I could end up with ids like: 2,5,6,9
I'm going to need to be able to search the products table looking for code ids for a specific set this is where I've come into problems trying to use id IN ($var) or FIND_IN_SET is proving problematic I've been advised to restructure it I'm happy to do just wondering what the best method would be.
Sounds like you have two choices. If this is a 1 to many relationship, then you need to have the foreign key in the code table, not the product table.
i.e.
codeId code productId
1 567902 2
2 345789 6
3 345678 9
4 345690 9
The other option is to have another table which contains productId and codeId (both as foreign keys), this is a many-to-many relationship. This is what you should go for if a code can be assigned to multiple products (I assume not). It will look something like this:
codeId productId
1 2
1 10
2 6
3 9
4 9
I think the first option is what you need.

SQL "shortcut" identifiers or a long string of joins?

QUESTION: Is it okay to have "shortcut" identifiers in a table so that I don't have to do a long string of joins to get the information I need?
To understand what I'm talking about, I'm going to have to lay ouf an example here that looks pretty complicated but I've simplified the problem quite a bit here, and it should be easily understood (I hope).
The basic setup: A "company" can be an "affiliate", a "client" or both. Each "company" can have multiple "contacts", some of which can be "users" with log in privileges.
`Company` table
----------------------------------------------
ID Company_Name Address
-- ----------------------- -----------------
1 Acme, Inc. 101 Sierra Vista
2 Spacely Space Sprockets East Mars Colony
3 Cogswell Cogs West Mars Colony
4 Stark Industries Los Angeles, CA
We have four companies in our database.
`Affiliates` table
---------------------
ID Company_ID Price Sales
-- ---------- ----- -----
1 1 50 456
2 4 50 222
3 1 75 14
Each company can have multiple affiliate id's so that they can represent the products at different pricing levels to different markets.
Two of our companies are affiliates (Acme, Inc. and Stark Industries), and Acme has two affiliate ID's
`Clients` table
--------------------------------------
ID Company_ID Referring_affiliate_id
-- ---------- ----------------------
1 2 1
2 3 1
3 4 3
Each company can only be a client once.
Three of our companies are clients (Spacely Space Sprockets, Cogswell Cogs, and Stark Industries, who is also an affiliate)
In all three cases, they were referred to us by Acme, Inc., using one of their two affiliate ID's
`Contacts` table
-----------------------------------------
ID Name Email
-- -------------- ---------------------
1 Wylie Coyote wcoyote#acme.com
2 Cosmo Spacely boss#spacely.com
3 H. G. Cogswell ceo#cogs.com
4 Tony Stark tony#stark.com
5 Homer Simpson simpson#burnscorp.com
Each company has at least one contact, but in this table, there is no indication of which company each contact works for, and there's also an extra contact (#5). We'll get to that in a moment.
Each of these contacts may or may not have a login account on the system.
`Contacts_type` table
--------------------------------------
contact_id company_id contact_type
---------- ---------- --------------
1 1 Administrative
2 2 Administrative
3 3 Administrative
4 4 Administrative
5 1 Technical
4 2 Technical
Associates a contact with one or more companies.
Each contact is associated with a company, and in addition, contact 5 (Homer Simpson) is a technical contact for Acme, Inc, and contact 4 (Tony Stark) is a both an administrative contact for company 4 (Stark Industries) and a technical contact for company 3 (Cogswell Cogs)
`Users` table
-------------------------------------------------------------------------------------
ID contact_id company_id client_id affiliate_id user_id password access_level
-- ---------- ---------- --------- ------------ -------- -------- ------------
1 1 1 1 1 wylie A03BA951 2
2 2 2 2 NULL cosmo BF16DA77 3
3 3 3 3 NULL cogswell 39F56ACD 3
4 4 4 4 2 ironman DFA9301A 2
The users table is essentially a list of contacts that are allowed to login to the system.
Zero or one user per contact; one contact per user.
Contact 1 (Wylie Coyote) works for company 1 (Acme) and is a customer (1) and also an affiliate (1)
Contact 2 (Cosmo Spacely) works for company 2 (Spacely Space Sprockets) and is a customer (2) but not an affiliate
etc...
NOW finally onto the problem, if there is one...
Do I have a circular reference via the client_id and affiliate_id columns in the Users table? Is this a bad thing? I'm having a hard time wrapping my head around this.
When someone logs in, it checks their credentials against the users table and uses users.contact_id, users.client_id, and users.affiliate_id to do a quick look up rather than having to join together a string of tables to find out the same information. But this causes duplication of data.
Without client_id in the users table, I would have to find the following information out like this:
affiliate_id: join `users`.`contact_id` to `contacts_types`.`company_id` to `affiliates`.`company_id`
client_id: join `users`.`contact_id` to `contacts_types`.`company_id` to `clients`.`company_id`
company_id: join `users`.`contact_id` to `contacts_types`.`company_id` to `company`.`company_id`
user's name: join `users`.`contact_id` to `contacts_types`.`contact_id` to `contacts`.`contact_id` > `name`
In each case, I wouldn't necessarily know if the user even has an entry in the affiliate table or the clients table, because they likely have an entry in only one of those tables and not both.
Is it better to do these kinds of joins and thread through multiple tables to get the information I want, or is it better to have a "shortcut" field to get me the information I want?
I have a feeling that over all, this is overly complicated in some way, but I don't see how.
I'm using MySQL.
it's better to do the joins. you should only be denormalizing your data when you have timed evidence of a slow response.
having said that, there are various ways to reduce the amount of typing:
use "as" to give shorter names to your fields
create views. these are "virtual tables" that already have your standard joins built-in, so that you don't have to repeat that stuff every time.
use "with" in sql. this lets you define something like a view within a single query.
it's possible mysql doesn't support all the above - you'll need to check the docs [update: ok, recent mysql seems to support views, but not "with". so you can add views to do the work of affiliate_id, client_id etc and treat them just like tables in your queries, but keeping the underlying data nicely organised.]