Eloquent ORM | Trying to understand relations in Laravel 5.6 - php

Stackoverflow.
I'm newbie to PHP and Laravel. I'm learning it by creating ecommerce shop system.
So the question is about Eloquent ORM and Relations in system.
I have Brands Catalog with Products that belongs to Brand. Than I want to create Catalog with Products, Types, Variants and Photos.
Project Scheme
On scheme below you can see the relations and DB migrations done now.
The Problem
What I have done:
Models relations;
Brand controller (simple CRUD with slug);
What I need to do:
Create adding Product logic (Only 1 ProductVariant).
When adding new Product, by default, it should create 1 ProductVariant with
datas (e.g. ASUS (Brand), ROG (Product), Notebook (Type), Zephyrus (Variant)).
Create adding Product logic (More than 1 ProductVariant).
When adding new Product, but Product has >1 ProductVariant(e.g. Intel (Brand), Core i7 (Product), CPU (Type) and Variants 7700, 7700K, 7600).
So, when I'm creating product (e.g. product/add.blade.php view).
With example form:
<form action="{{ route('name of add route) }} method="post">
here goes brand select with options (foreach brands as brand)
than goes type select with options (foreach types as type)
than goes inputs for Product (name, country, etc.)
than goes inputs for ProductVariant (name, description, price, etc.)
than goes inputs for another ProductVariant.
</form>
The Question
Am I done all relations correctly?
How should I store this data in DB in Controller?
Also, I have Controllers for Product, ProductVariant, ProductType.
I will be very grateful if someone can help me

It's too long to write whole code here or describe how to save relational data in laravel.
Please have a look official documentation and this small tutorial
Connected with correct relationships
Depending on your example I think that you need to have additional description fields for tables Product and ProductVariant, to store short info about product or concrete variant of product.
Also I think that will be a lot of product photos, which will be independent of product variant (will be the same for all variants of that product). To do not have duplicates of photos for each variant you can change ProductPhotos table structure:
id
product_id - belongs to Product
product_variant_id - belongs to ProductVariant (NULL if its for all variants of that product)
photo_url
So to get all photos for concrete variant of product you can get
all photos for that product which are not connected with variant
(product_variant_id IS NULL)
plus all photos for that variant

Related

What table structure is better for categories and custom user categories

I have a categories and users table. A user can have many categories and a category can have many users (many to many). However, I also need a feature were users can insert/create their own categories and which is only accessible to the user (category creator) + the defaults categories.
I created a pivot table to handle the many to many relationship, however, I was having difficulty deciding if I need to create another table to handle the custom user categories or just add a user_id on the categories table.
What would be the correct structure I should take/create to handle this.
Thanks.
Given the information you have described, there are two solutions which would be valid: one would be to have a separate table for custom categories, and my preferred solution, would be to have a boolean value on the categories table which indicates whether a category is custom or not. This gives you the following advantages:
Logic applied to the two similar kinds of category remains the same
Other fields which are shared can be kept, in kind
If you wish to convert a custom category to a real category, this then becomes trivial (change the boolean)
You could include a creator id field to identify the person to whom the category applies, alternatively, you might simply designate in-code that custom categories may only have one member.

MySQL User with Roles, Role specific fields?

I have an application where a User can be a Supplier or a Shop.
Now these 2 roles have very different role-specific fields..
Basically, a Shop can make Orders to Suppliers.. So a Shop can make Orders and a Supplier will receive those Orders.
Where would I put these fields for good practice?
Add them all on the User class, with nullable types (doesn't seem right!)
Create a different class for each Role. So we have a Supplier class with a user_id and Shop class with a user_id, I would have to query these fields using $user->supplier->field or $user->shop->field...
Neither of these seems like thé way to go. Any idea's?
Thank you!
You don't have to stick with a single users table. You can have a Supplier model and a Shop model (with suppliers and shops tables).
Then in the config/auth.php file, you can set up a new auth provider using the Eloquent driver but with a different model. You can then assign those providers to any new guards that you create.
You can read more about authentication and authorisation here:
https://laravel.com/docs/5.4/authentication
https://laravel.com/docs/5.4/authorization
Edit
After it was mentioned in the comments about polymorphic relations, I think that would apply better for this type of relationship (multiple types of users, each with own set of fields).
Read more here:
https://laravel.com/docs/5.4/eloquent-relationships#polymorphic-relations
Can a user have multiple shops or supply multiples? Your second option seems fine.
User hasMany: supplier, shop
- id
- name
Supplier belongsTo, hasOne: user
- id
- user_id
- fields_supplier
Shop belongsTo, hasOne: user
- id
- user_id
- fields_shop
$user->supplier->fields_supplier;
$user->shop->fields_shop;
$supplier->user->name;
$shop->user->name;
--
If you had more info on how you wanted it to work, it would help.
"Supplier" is a role played by a "Party" ("Individual" or "Organization")
Your store may get a Catalog from a Supplier, and may Request Quotes from them.
Your store creates "Purchase Orders" and sends them to the Supplier, and they send you "Order Responses"
A Supplier is not a user. You could create "User"s for their employees though
Why not just use an existing ERP like Odoo?

many to many insert php and database architecture

I am doing a database for a project and im stuck in a point.
Since every product can have multiple field of use, but even every materials can have multiple field of use, i come up with that solution.
THis is my database architecture.
http://i57.tinypic.com/2mhc03o.jpg
product are specifical for every material e.g. there can't be the same product for 2 material
material are leather, simil-leather, cloth, PVC
field of use are the field which that material can be used: sport, leisure, work
The problem is that material can be used in many field and many field can be used for a material, so it's N:M
Every product can be used in many field and many field can be used for a product so it's too N:M
For example, leather can be used in work, sport, cloth in work sport and office
product can be used in some or all field of application and vice versa.
1)WIth my architecture, to retrieve a material that can be used in a specific field of use i need to do 4 JOIN between all the table. Is it ok? or it's too long?
2)Also, when the user want to add a new category, to insert which field of use that category can have, i need to have a product already for that category.
3)when i want to fill a many to many relationship, i need to do it manually in the conjuction table (field_of_use_product) with some php codes right?
You need three joins for four tables that involved.
No, product may insert after all of the data at foreign tables have inserted.
Yes, it's a simple insert if you know the foreign keys.

The right database structure and model relations in CakePHP for my project (small shop)?

I have a pretty simple shop-system. I'm working with CakePHP. Actually I wouldn't call it shop, it's rather a basic form where you can type in your data and which items in which color you want and that's it.
There is one buying-form which is "open to the public" and then there are buying-forms which are password secured.
The latter ones have a selection of the items (or selection of colors) which you get on the public site, but have discounts.
I want to save the orders in a database. I have a table orders and ordered_products. That's working fine.
It works pretty good, but only because I made something not very good: Since there are just a few products I just wrote an array in the controller with the names, prices and stuff... the discounts or selection of products I handled by just overwriting the products-property.
Well, putting data in the controller is not really the idea behind the MVC-Structure, so I was thinking about who to handle the products, the selection of products for the different password-secured buying forms and the discounts with models.
My idea was, to create the following tables:
products (id, name, price,...) -hasAndBelongsToMany Color
colors (id, name)
products_colors (product_id, color_id)
Now to set in which "closed-area", which products in which color and with which special price can be ordered I thought of the following tables (the actual table and field names are of course not wise chosen, but just for the idea):
product_selections (id, closed-area_name, product_id, special_price) hasAndBelongsToMany Color
product_selections_colors (product_selection_id, color_id)
When I'm creating the public buying form I would just use the top three tables. but building the "closed-area" I would use the bottom two, selecting the product_ids and special_prices from product_selection as well as the different colors over the product_selections_colors-table for the according "closed-area" (i dont know a better name for that right now...). with the product_id i would get the other information about the product from the table products and create the buying form with this data.
I want to have it all in a database, because then I can better work with the orders (creating receipts, deliverynotes etc.).
I would like to know what you think about that, because I have the feeling that I'm going totally in the wrong direction, since it feel way to complicated for such a simple thing...
I hope you can help me.
Based on your description, I would recommend doing it this way:
Have a users table with a field for "group_id". This allows you to have multiple users with login privileges that all can view the same options or colors based on their grouping.
In the case of a general (non-logged in) user, the assign the group_id to default to 0.
Next, ditch the product_selections and product_selections_colors tables.
You don't want to have to repeat products across tables.
Simply add a new table that pairs which product ids can be purchased by which group_ids. (HABTM relationship in cake)
You will obviously need to tweak this general setup to work specifically for your needs.

CakePHP naming conventions/file structure

I'm quite new to CakePHP so I'm wondering if anyone can help me with how to order my pages.
I have a table of products (with a Product model and products_controller).
I also have a table of categories (with a Category model and categories_controller).
The categories hasMany products.
Firstly, is the name categories incorrect to call it. According to CakePHP convention, what is the correct name to call it?
Secondly I would like the user to click on the products link and then be presented with a list of categories and finally, once he/she chooses a category be presented with the products in that category. How would this be laid out?
You're asking some pretty basic CakePHP stuff, I suggest you read the book, which outlines naming conventions, file structure and data retrieval to name a few things.
That being said, the name categories is correct, unless you want products to have more than one category, the relationship will be Product 'BelongsTo' Category.
To get category info inside the product controller you can just access it's find methods with $this->Product->Category->find();, but again I recommend you read through the CakePHP book as you go to build up our knowledge and learn more about the framework you're using.
You mean that categories is not a plural of category? I think so. Your table has to be named as 'categories'.
Secondly, I think that you need a Categories hasAndBelongsToMany Products (HABTM) in your model, so every Category has many Products, and also a Category belongs to many products.
Use the 'cake bake' command and you will see easily if it is what you want.
Hope it helped, althought I'm quite new in cakePHP as well...
Alf.
If you have categories tables in db, its controller would be categories_controller.php and the Products belongsTo Category will work if products belong to only one category. No need to HABTM relationship. See in cakephp the model files are in singular form and controller file are in plural form with controller attached with them. The tables are named in plural in db.
Regarding ur 2nd question, I think im not getting it exactly.

Categories