Imagine that I have two couriers and some packages:
|name|proficient
|Jon |cats
|Mike|bugs
|item|container
|cats|cage
|bugs|jar
The trick is, if courier is proficient with bugs, then he will carry them in a jar. If not, he will carry them in a box.
Should this be made in the client side or I should make another container? or should I make two types of container for the same item and choose right one with the trigger?
Related
I am a beginner and this is my first real project.
The below image shows what I have been trying to reach. But it got way complicated so fast and confusing. So I'm asking if there are different ways to design the tables easier with few keys in mind:
attributes won't duplicate.
colors,sizes,materials tables have different structures e.g.(colors
have name_ar,name_en,and path for the image of the color).
I wasn't using SKUs in the beginning, But now I think I may need
them to separate.
Different colors may have different sizes and so on
This is what I have reached so far
#Edit-1:
I tried to think about another way to design it but it grew more than the previous on with one table more
.
But after that I couldn't think of another way to reach the result that I wanted.
Thanks for all the answers in advance
It looks like you're trying to do EAV architecture here, but don't really understand the point \ problems with it.
The point of EAV architecture is to build the database vertically vs horizontally. It looks like you're just creating a bunch of pivoted attributes, vs actually EAV design. What this means in practice is that instead of:
Table: Shirts
Columns: ID, Label, Size, Color, Weave, Fabric, Made in, Class, Discount blah blah blah
You Want:
Entity:
ID:1, [Label:'Cool Shirt', Price: 19.00, Other required properties]
Then your attributes tables
attribute:
entity: 1
attribute:type
value: shirt
attribute:
entity: 1
attribute:color
value: red
attribute:
entity: 1
attribute:size
value: large
The point of this style of architecture is that not all entities need all attributes, and you don't wanna make a super long table with every potential property an entity could possess.
You can go further down the pivot tables which is what it looks like you were trying to do here with the pivoted ID \ naming:
attribute_values:
entity: 1
attribute:3
value: 5
Table attribute_map:
id: 3
value:"color"
Table property_map:
id:5
attribute:3
value:"red"
Regardless few major things.
Parent should be a property of the subtables themself that's the 'entity' part. No need for another table mapping relationships. Also makes it a lot easier to run down recursive calls to get what you want as the final answer)
Things like price don't (usually) fit into this model well and should also be assigned as a column on the top tier entity as well. Keep that in mind when you're deciding how to structure your top tier entities.
Make sure to add composite indexes to all of your pivots.
Edit for what you wanted what you're trying to do:
So keep in mind every entity is just a collection of properties.
Enitity 3: Shirt, White, XL
Enitity 4: Shirt, White, X
Shirt-White-X is the "SKU" as far as your database is concerned in EAV.
You just recursively progress down all of the tree until all properties \ sub-properties are fully expressed.
Keep in mind an "entity" is just an amalgamation of properties which in this case you also want to operate as a unique key (basically a SKU). Bonus you can use unique indexes to enforce it.
From (exactly) what you said you're just trying to work out inventory, which can be done a few ways. Generally you'd just make another tier (guessing as I don't know what you're actually trying to do).
Table: Inventory
Id (store): 1
Attribute (product_id): 4
Value (inventory): 7
You can create a higher tier entity like a store and actually create product objects assigned to the store. Really depends on how your system is modeled and how far down the rabbit hole you wanna go.
This is getting a bit more into abstraction \ what you're actually doing \ how your overall architecture works.
It's rarely useful to be an EAV purist. Properties like price that will be attached to every product entity are usually easier just to add directly to the top tier entity. You're not trying to re-build magento here and there's some major downsides to pure EAV architecture as it gets more convoluted. It can be very flexible. It can also create insanely inefficient systems depending on how it's built (hello medical industry).
I have collected a bunch of crafts and DIY instructionals over the years. Each has a list of instructions and a list of materials needed.
I want to store these in a database, but as I have limited experience I'm questioning the correct/proper way to structure and Design the database for SQL.
Initially I was going to put everything in one table, so each record would represent a project, and then there would be one field for the instructions and one field materials. Each set of instructions would go into one value, perhaps separated by some character or symbol.
However, I'm wondering if it's better to separate the instructions and materials into their own tables (a table for each instruction set for each project). But with this method, there would have to be hundreds of tables if I create a table for each set of instructions for each project.
The third option would be to put ALL the instructions for each project into one table, then give them an id for the corresponding project, and an id for the order they should appear. But this would mean possible duplicates, especially in the materials table (hammer, for instance would appear multiple times, but would have separate ids referring to separate projects). I also worry about the table being too big with thousands of entries.
The fourth option would be to have one table, but add an excessive number of fields for instructions and materials, and only use the ones needed for each project (for example 100 "materials" fields, but perhaps one project only uses 10 and the other 99), but this does not seem proper, and could lead to trouble later on.
Is there a standard way to go about solving this problem, structuring a database for a list of things, which each reference another list of things?
The Django docs say you can put a many to many field in either side's model, but not both. Example showing Pizzas and Toppings says it's more "normal" to think of the toppings on a pizza than think of which pizzas a topping is on, so put the field in the pizza model. OK...
However, in my application which tracks permissions and groups, this is not necessarily true. The application has a many-to-many in the permissions table showing which groups have that permission. It also seems like you should be able to look at a group and see what permissions it has. This would theoretically use the same join table.
Couldn't I add a many-to-many-through field in the groups model and specify the existing permission_group join table? Would this cause problems, as it directly violates the recommendation in the ManyToMany documentation?
Thanks...
I can't really see the reason for it. It doesn't matter which end of an electrified wire you touch - the end result is the same. What happens on the database level is exactly the same with no regard to where you add the field in Django. You can still do reverse lookups from either side (check out documentation about related_name setting, it's handy) so you can get both
a) all persons with some specific permissions
b) all permissions that a user has
If you try what you propose, you will end up with two parallel M2M fields if Django allows that - and I imagine it does, but that doesn't make any sense at all. It's like talking to the same person over two phones at the same time - why would you do that? Don't.
And as Patrick mentioned, Django has a comprehensive permissions system so you might just want to check that out and maybe it will suit your needs without any effort on your part at all.
You're making a distinction where there is none. The point of a many-to-many is that it is automatically accessible from either side of the relationship; Django does that for you. The point the docs were making was that the difference is a semantic one only; in the case they mention, toppings belong to pizzas. But even doing it that way, you can still access the pizzas from each topping.
Right now I have a database in phpMyAdmin, and off the the side of the screen, it shows the database name, and a list of tables inside the database. It's fine if it's only a couple of tables, but when there's dozens of tables, it gets hard to find the tables I want to edit. I've thought about creating another database to make it easier to organize, but then I'll have to connect using the different database's name and a different user login for the database, and I just thought how much easier would it be if I can make folders or something similar inside the database I already have to organize my tables. I'm wondering if something like this is possible, or anyone know any work-around this issue.
Well, you can't create a database (or folders) within a database; that's just not something MySQL is able to do.
phpMyAdmin has a grouping feature that may help your situation. By default, databases with a prefix followed by _ (a single underscore) will be grouped together, as will tables with __ (two underscores).
Here's an example of how this ends up looking when grouped:
Database:
Table:
If you're able to rename some of your tables, you'll be able to take advantage of the grouping feature to make the phpMyAdmin display a bit more manageable. Of course, this won't change the way other tools display the table list.
The configuration directives $cfg['NavigationTreeDbSeparator'] and $cfg['NavigationTreeTableSeparator'] control the separator used. The relevant documentation starts at http://docs.phpmyadmin.net/en/latest/config.html#cfg_NavigationTreeEnableGrouping and includes the next few line items.
I'm writing a CMS for various forms and such, and I find I'm creating a lot of drop-downs. I don't really feel like mucking up my database with tons of random key/string value tables for simple drop-downs with 2-4 options that change very infrequently. What do you do to manage this in a responsible way?
This is language-agnostic, but I'm working in Rails, if anyone has specific advice.
We put everything into a single LookUp table in the database, with a column that mapped to an enum that described which lookup it was for (title, country, etc.).
This enabled us to add the flexibility of an "Other, please specify" option in lookup dropdowns. We made a control that encapsulated this, with a property to turn this behaviour on or off on a case-by-case basis.
If the end user picked "Other, please specify", a textbox would appear for them to enter their own value. This would be added to the lookup table, but flagged as an ad hoc item.
The table contained a flag denoting the status of each lookup value: Active, Inactive, AdHoc. Only Active ones would appear in the dropdown; AdHoc ones were those created via the "Other, please specify" option.
An admin page showed the frequency of usage of the AdHoc values, allowing the administrators of the site to promote common popular values into general usage (i.e. changing their Status flag to Active).
This may well be overkill for your app, but it worked really well for ours: the app was basically almost entirely CRUD operations on very business-specific data. We had dozens of lookups throughout the site that the customer wanted to be able to maintain themselves. This gave them total flexibility with no intervention from us.
You cold have one single dropdown table with an extra column to say what the drop down is for... limit the results with a where clause...
At my current position, we implemented a LookupCode table that contains a CodeGroup,Code, and Meaning column, as well as some others (like active). That way you have a single table that contains all of your lookup values are in a single location and you can do some quick lookups to bind to your dropdown lists.