I want to create a database for online shops, my database has "Commodity" and type of "Commodities". Before that I want to create its dynamic I create 2 tables for Commodity and CommodityType.
For example, "Mobile" category has many details like:
cpu
ram
internal storage
battery
etc.
and external "Hard Category" has details like:
capacity
waterfall
armor
hasAdaper
etc.
I want the admin of my website to be able to add new a category that may have new properties; then add related "Commodity" to it.
My problem is how to design my database and tables?
I think that when the admin adds a new category, the system must make a new table with properties that the admin defines for this category.
Is that how to do it, or can you suggest a better way?
You're probably looking for an Entity-Attribute-Value Model
I see two approaches :
Define a specialized table with the custom fields when the new product type is created.
Have a table CustomProperties, where you list the properties, a table TypeProperties, where you save which type has which property, and finally a table PropertyValues, where you store the values, each value a line.
Related
I have to build an inventory management system for my school and this is the problem that I'm facing:
There are multiple types of equipment that I have to store in my system:
Computers, Printers, Cartridges, Projectors, Mouses, Keyboards etc.
And there is some common data about each item, regardless it's type:
TEMSID (like a barcode), SerialNumber, PurchaseDate, RegisterDate and other, see item entity for more.
Also, each item type has it's specific fields that have to be stored.
This is how I am going to deal with it, however I'm not sure about it:
[item] table stores common data
[item] table has one to one relationships with other tables which store more details about specific items.
Repetitive data (Manufacturer, Model, Resolution etc.) is stored in other tables [itemType] to reduce redundancy.
Ignore those FK IDs from item table
I fell like it is a bad design.
If there is another more efficient solution, I'm ready to start designing from scratch.
Thank you in advance!
Ask yourself: what happens, if the school gets an item, for which you don't have any table (f.e. like Printer and PrinterType) in your database? And if this can happen often? Then you have to add new tables to the database each time.
On the other hand, you have type specific properties, but yet they can be common, like model or color.
If I were you, I would make a dynamic system, which means, the administrator/user can add any item (device) type and can add any properties to it.
I would design the db like this:
We have device types like printer, projector, etc. Then we have our devices table with the basic data and connected to the devicetypes table. Then we have a properties table, in which we hold the other properties of all the device types (one property only once, no redundancy). And finally, we have a propvalues table, where we store the different property values of each device.
F. e. in the above example, the device with id: 1 has two properties (model and color) with the values hp and true.
With this design, the user/administrator can manage as many properties as many he want.
One special thing: the value field should be f. e. a string field, because it can hold values like numbers, string, dates, etc. And in the view you have to cast this value depending on the datatype.
And if you have to manage compatibility data too, of course you can do it more generic. But maybe this should be a homework :-)
Creating a database for a project and well i sort of understand the concept of database but i don't know where to start. I know for my database i need to have the following:
Brand of the phone, model, some feature like size, operating system and touch screen?
To make this more like a database i decided to add more information such as carrier. So am thinking to make a database i would need these tables:
Mobile: ID phone(Primary key), Brand, Model
Phone: Model, size, and touch screen availability
Carrier: service provider, phone Id
The question is would this be a efficient database or should i combine the mobile and phone table? If this isnt good then what's the best way to make an collection system of cellphones?
You seem to be on the right track.
I would even say to break up the brand and model into 2 different tables.
To learn more about this relationship read this article
Database Relationships
MobileDevice
IDDevice, IDBrand, IDModel, IDCarrier
MobileBrand
IDBrand, BrandName
MobileModel
IDModel, IDBrand, ModelName, Size, TouchScreenAvailability
Carrier
IDCarrier, serviceprovider
Steps of creating a database for new application
Identify all functional entity
Create separate tables for each of them
Note: While creating it please follow normalization rules
Once functional entity related table creation is done than based on there relationship create corresponding tables to represent relationship
After that create your application related transacional tables
For any of sensitive type of transaction create tracking/history table(s)
For all lookup/referring related object create corresponding lookup tables
Note: While creating database for an application please consider few points like
scalablity of that application
scope of that application
target users, there location, type of user
Hope it make sense to you in order to start creating database for your application
I'm creating a database of motorcycle and was wondering what the best way to go about setting it out is.
i would like to normalise the data as best as possible so save any headaches further down the line.
I anticipate having the following tables so far:
Manufacturer
ID,name,country,image
Model
ID,name,manufactureID,engine_size,power,torque,description,weight + various other specifications
I'll also want to separate models by type,so should I have a another table with the details below or should I just include this in the model table?
Type
ID,Sports,Supersports,Touring,Cruiser,Off-road
Similar to the type, I want to categorise motorcycle by licence type. Again should I create a separate licence table or just have it as a string in the model table.
I'll need front end users to be able to search the database based on type, licence, manufacture and model.
I'll need them to be able to sort by things like weight, power etc..
Is there a best practice approach to this?
Yes, you should create another table for TYPE and add a reference in Model table.
Yes, you should add licence type also.
To sort them by weight,power; you can do it just from your model table.
I'd like to design a cloud business solution with 4 default tables, a user may add a custom field(Column?) or a add a custom object(Table?).
My first thought was to create a new database for each account but there's a limit to database number on a sql server instance,
2nd solution : for each account create a new schema by duplicating the 4 default tables for each schema.
3rd solution : create 4 unique tables with a discriminant column (ACCOUNT_ID), if a user wants a new field add a join table dedictated to that ACCOUNT_ID, if he wants a new object then create a new table.
What are your thoughts? Does any body know how existing cloud solutions store data? (for instance salesforce)
BTW, I don't want to create a VM for each account.
Thanks all for your suggestions, that helped me a lot especially the microsoft article suggested by John.
Since few architectural points are shared between accounts (the 4 default tables are just a suggestion for the user, I expect a full customization), I've opted for the schema per account design with no EAV pattern.
I want to create a product catalog that allows for intricate details on each of the product types in the catalog. The product types have vastly different data associated with them; some with only generic data, some with a few extra fields of data, some with many fields that are specific to that product type. I need to easily add new product types to the system and respect their configuration, and I'd love tips on how to design the data model for these products as well as how to handle persistence and retrieval.
Some products will be very generic and I plan to use a common UI for editing those products. The products that have extensible configuration associated with them will get new views (and controllers) created for their editing. I expect all custom products to have their own model defined but to share a common base class. The base class would represent the generic product that has no custom fields.
Example products that need to be handled:
Generic product
Description
Light Bulb
Description
Type (with an enum of florescent, incandescent, halogen, led)
Wattage
Style (enum of flood, spot, etc.)
Refrigerator
Description
Make
Model
Style (with an enum in the domain model)
Water Filter information
Part number
Description
I expect to use MEF for discovering what product types are available in the system. I plan to create assemblies that contain product type models, views, and controllers, drop those assemblies into the bin, and have the application discover the new product types, and show them in the navigation.
Using SQL Server 2008, what would be the best way to store products of these various types, allowing for new types to be added without having to grow the database schema?
When retrieving data from the database, what's the best way to translate these polymorphic entities into their correct domain models?
Updates and Clarifications
To avoid the Inner Platform Effect, if there is a database table for every product type (to store the products of that type), then I still need a way to retrieve all products that spans product types. How would that be achieved?
I talked with Nikhilk in more detail about his SharePoint reference. Specifically, he was talking about this: http://msdn.microsoft.com/en-us/library/ms998711.aspx. It actually seems pretty attractive. No need to parse XML; and there is some indexing that could be done allowing for simple and fast queries over the data. For instance, I could say "find all 75-watt light bulbs" by knowing that the first int column in the row is the wattage when the row represents a light bulb. Something (NHibernate?) in the app tier would define the mapping from the product type to the userdata schema.
Voted down the schema that has the Property Table because this could lead to lots of rows per product. This could lead to index difficulties, plus all queries would have to essentially pivot the data.
Use a Sharepoint-style UserData table, that has a set of string columns, a set of int columns, etc. and a Type column.
Then you have a list of types table that specifies the schema for each type - its properties, and the specific columns they map to in the UserData table.
With things like Azure and other utility computing storage you don't even need to define a table. Every store object is basically a dictionary.
I think you need to go with a data model like --
Product Table
ProductId (PK)
ProductName
Details
Property Table
PropertyId (PK)
ProductId (FK)
ParentPropertyId (FK - Self referenced to categorize properties)
PropertyName
PropertyValue
PropertyValueTypeId
Property Value Lookup Table
PropertyValueLookupId (PK)
PropertyId (FK)
LookupValue
And then have a dynamic view based on this. You could use the PropertyValueTypeId coloumn to identify the type, using a convention, like (0- string, 1-integer, 2-float, 3-image etc) - But ultimately you can store everything untyped only. You could also use this column to select the control template to render the corresponding property to the user.
You can use the Value lookup table to keep lookups for a specific property (so that user can choose it from a list)
Summarizing lets look at the options under consideration for storing product information:
1) some xml format in the database
2) similar to the post above about having x number of type defined columns (sharepoint approach)
3) via generic table with name and type definitions stored in lookup table and values in secondary table with columns id, propertyid, value (similar to #2 however this approach would provide unlimited property information
4) some hybrid of the above option where product table would have x common columns (for storage of properties common with all products) with y user defined columns (this could be m of integer type and n of varchar types). This may be taking the best of #2 and a normalzied structure as if you knew all the properties of all products. You would be getting the best sql performance for the properties that you use the most (probably those that are common across all products) while still allowing custom columns for specific properties with each product.
Are there other options? In my opinion I would consider 4 above as the best hybrid of the combinations.
dave
Put as much of the shared anticipated structure in traditional normalized 3NF model, then augment with XML columns as appropriate.
I don't see MEF (or any other ORM) being able to do all this transparently.
I think you should avoid the Inner Platform Effect and actually build tables for your specialized entities. You'll be writing specific code to manage them so why not have proper backing tables too?
It will make your deployment slightly harder - drop in an assembly and run a script - but it will probably save you a lot of pain in the long run.
Jeff,
we currently use a XML field in the Products table to handle all product-specific data. So our Products table has a few common fields that all products share, an XML which contains whatever a particular product needs additionally, and a few computed fields that grab into the XML and surface some of the frequently queried fields as "virtual" fields on the Products table (e.g. "Style" would be set to whatever the current product defines, or NULL, if the product doesn't have a Style property).
So far, we've been quite flexible with that approach - if you create some decent XSD schemas for your XML, you can even create C# proxy classes for these fields.
Works nicely for us - joining the best of both the relational and XML worlds.
Marc