I need to design the structure of the tables with the product data to meet the following requirements:
1. A product consists of the following fields: EAN, CN, description, pvp
2. There are several types of users that access the products. The user types are not stable, they can be added or deleted at any time.
3. Any of the fields of the products may vary depending on the type of user who views it. For example:
We have three users:
1 - John - guest
2 - David - client
3 - Vicent - vip
We have this product with this data by default:
8470001234567 - 123456 - Iphone X - $799
Guest users instead of seeing this data see the following:
8431239876547 - 987654 - Iphone X - $849
The client users see the data by default and the vip users see:
8470001234567 - 654321 - Iphone X Sale - $709
This means that a user sees the default data of a given product unless there is an exception for its type. The exception can affect any field (except the id).
I can think of this structure:
PRODUCTS: id, ean, cn, description, pvp
PRODUCT_EXCEPTION: product_id, user_type_id, ean, cn, description, pvp
I have verified that with this structure many queries are made, do you think of a way to optimize this so that it is not necessary to make so many queries?
Note 1: the products are contained within offers that have a certain number of products.
Note 2: I use Laravel. The Offer model has a relationship with products, that is, I obtain the products in the following way: $offer->products()
Looking at just the problem description, I ended up with this, which is equivalent to what you are proposing with your Product_Exception:
Reasoning:
Since user types vary, you cannot put the values directly in the Product table. Ex. 3 user types == 3 prices. Not here. So you need a link table between Product and UserType.
The link table will contain the characteristics of 1 Product, for 1 UserType.
If you want to have a default value, you can put the characteristics in the Product table as well. But then your queries become bigger! Check if there is an exception value, if not use the default.
So your solution makes sense to me.
Related
I am creating free accounting package in libreoffice-base to compete already available ones your contribution is appreciated. the package include tables:
items
item_groups
order_details
sales_bill_desc
cash
units
companyinfo
bill sales
Customer_ledger
etc.
and created two forms
first to enter items in items table with following fields:
id
List item
particulars
units from units table linked with id gst chooses from
tax table related as id basic price basic stock, barcode, group,
subgroup,
second form is sales bill entry form
it contains a form which relates to order_details table selects customers name from ledger where its state code is also defined e.g. for punjab its 03 basically it is picked from customer's GSTIN number
a subform which is connected to sales_bill_desc table related to order_details table with bill number in both tables.
now in subform when we enter one item, its name is displayed which is same entered in sales_desc table additionally it also need automatically display item units, gst, price(editable field but basic price must be displayed there).but it does not. how to do that i have studied books but am lacking i created same in access 2016 somewhere which worked fine (full working package accounts with inventory).At this time,I am trying to use same database but advanced with features such as barcode. Of course the issue is to be resolved if someone can help. I am loading code of the package.Please rectify and update.
I've looked through dozens and dozens of Eloquent questions, however the examples are usually simple to grasp. E.g. a User has one Phone or a Category has many posts.
I'm trying to store the product features and build relations between them while keeping the database as closed to normalized as possible, otherwise it'd be easy to just store each combination and its data in a single row.
Consider a product, it can have many features ( Material, Size, Weight, Color etc. ). Each feature assigned to a product can only have one value, for example, the Material is Wood.
To keep away duplicate entries, I'm keeping the Features and Values in separate tables. Because for example Wood can be used both by Material and Texture.
Here's my DB structure:
feature
- id
- name ( E.g. Material )
feature_value
- id
- value ( E.g. Wood, must be unique )
feature_value_combination
- id
- id_feature
- id_value
product_feature
- id
- id_product
- id_combination
This way I can also group them and prevent duplicates. But I'm having a hard time understanding the relations between these, because a lot of relations can work. My questions are:
How many Eloquent do I need? Do combinations need their own Eloquent?
What are the relations here? Because it makes sense that a feature value belongs to a combination, but also have a combination, while belonging to a feature name and a product, and also a product can have a feature, a value, a combination. Everything seems mixed up here.
Any help toward clarifying this is appreciated.
Update
I managed to setup the basic relations, but at the cost of creating 5 models, even for pivot tables.
Models:
M1) Product
M2) FeatureName
M3) FeatureValue
M4) FeatureNameValue
M5) ProductFeatureNameValueRelation
Now I can fetch a product and its feature data using this:
Product
::where( 'id', $id )
->with( 'getM5data.getM4data.getM3data')
->get();
I used short names to make it easier to read. Each of those methods fetch the required data using a relation. However, this results in 5 queries, which is an abomination:
select * from `products` where `id` = 1
select * from `product_feature_relations` where `product_feature_relations`.`id_product` in (1)
select * from `product_feature_name_value` where `product_feature_name_value`.`id` in (2, 3)
select * from `product_feature_values` where `product_feature_values`.`id` in (4, 5)
select * from `product_feature_names` where `product_feature_names`.`id` in (6, 7)
This can be done easily using inner joins and 2 queries. I'm not sure how to convert the above to this.
I am working on a PowerBI report which requires RLS.
To simplify, let's say I have the following tables:
Table 1:
Sales, Account, ProductOwnerAccount, Owner, Region
Table 2
Userid, UserRegion, UserAccount
Scenario: Need to show two sets of tabular data:
All Rows Where Account = UserAccount and Region = UserRegion
All Rows where ProductAccount = UserAccount, Account <> UserAccount and Region = UserRegion
The only way to achieve this seems to be RLS and using two roles with corresponding DAX filters.
However, if I apply two roles to the same user, the least restrictive one takes precedence and hence, both report will give the same result.
I tried to create a calculated table, but that does not allow using USERPRINCIPLENAME as a filter.
I also tried to have a page level filter which could use a measure (which in turn uses USERPRINCIPLENAME()), this is also not allowed.
Similarly, a calculated column on each row to specify if it's owned by the current user doesn't work.
Is there any other way? Am I missing something very basic?
Which tables are connected with the process of reindexing of index in magento.
Please share any documents available for the same.
Can't take credit for this as it is taken from original post at: Can someone explain Magentos Indexing feature in detail?
Magento's indexing is only similar to database-level indexing in spirit. As Anton states, it is a process of denormalization to allow faster operation of a site. Let me try to explain some of the thoughts behind the Magento database structure and why it makes indexing necessary to operate at speed.
In a more "typical" MySQL database, a table for storing catalog products would be structured something like this:
PRODUCT:
product_id INT
sku VARCHAR
name VARCHAR
size VARCHAR
longdesc VARCHAR
shortdesc VARCHAR
... etc ...
This is fast for retrieval, but it leaves a fundamental problem for a piece of eCommerce software: what do you do when you want to add more attributes? What if you sell toys, and rather than a size column, you need age_range? Well, you could add another column, but it should be clear that in a large store (think Walmart, for instance), this would result in rows that are 90% empty and attempting to maintenance new attributes is nigh impossible.
To combat this problem, Magento splits tables into smaller units. I don't want to recreate the entire EAV system in this answer, so please accept this simplified model:
PRODUCT:
product_id INT
sku VARCHAR
PRODUCT_ATTRIBUTE_VALUES
product_id INT
attribute_id INT
value MISC
PRODUCT_ATTRIBUTES
attribute_id
name
Now it's possible to add attributes at will by entering new values into product_attributes and then putting adjoining records into product_attribute_values. This is basically what Magento does (with a little more respect for datatypes than I've displayed here). In fact, now there's no reason for two products to have identical fields at all, so we can create entire product types with different sets of attributes!
However, this flexibility comes at a cost. If I want to find the color of a shirt in my system (a trivial example), I need to find:
The product_id of the item (in the product table)
The attribute_id for color (in the attribute table)
Finally, the actual value (in the attribute_values table)
Magento used to work like this, but it was dead slow. So, to allow better performance, they made a compromise: once the shop owner has defined the attributes they want, go ahead and generate the big table from the beginning. When something changes, nuke it from space and generate it over again. That way, data is stored primarily in our nice flexible format, but queried from a single table.
These resulting lookup tables are the Magento "indexes". When you re-index, you are blowing up the old table and generating it again.
I have a large amount of shop items imported into elastic search and I can query them.
I am wondering how best to model the following mysql table relationship into elastic search:
Shop items can have different offers. There are different offer types. And in some shops an item may be on offer, in other shops the item may not be on offer or have a different offer type. Items don't have to have offers. I model this below:
Items table
item_id
Offers table
shop_id, item_id, offer_type, user_id
Where user_id is the id of the user who created the offer.
So as an example, item_id 1 and shop_id's 1,2 and offer_types premium and featured.
Then the offers table could look like:
shop_id, item_id, offer_type, user_id
1,1,featured,45
2,1,premium,33
2,1,featured,45
But it's not the case that every item is on offer. And even if item_id 1 is on offer in shops 1 and 2, it might not be on offer in other shops.
I want to be able to query my /items type and it will only be for one shop at a time but for that shop I want to get all the items in e.g. a certain price range and of a certain category (that i can do all ready), but I need to know for each item in the results what offer they have if any (e.g. if featured, premium or whatever offer_type).
How can I best model this behaviour in elastic search?
One approach is Nested Object relationship - Shop contains set of items with id as your shop id
For your cases
1) Get all items of a shop - GET: http://host/your_index/shops_type/shopid
This will give you all items in a shop along with offer_type. you can filter in your program logic