This is complicated and difficult to explain, but here it goes. I have created a db that works just fine. It is a time saver, but not efficient for the user. I have a form for the merchandise where the user selects a paper type from a combobox. They are presented with two choices. They must also select a print size from another combobox. They are presented with 5 choices. I have VBA code that creates a SKU number based on these selections.
An art piece can use both paper types and be available in all 5 sizes. What I am trying to figure out is how I can offer all the possible choices on this form, allow the user to select options for that piece. As an example, the user chooses both paper types and all print sizes. This would create 10 SKU numbers for one art piece. Below is a copy of the form in it's current view:
Is this possible to do from one form? If so, how can this be accomplished in the most efficient way? I feel that it can. In VBA, this would be an IF nest nightmare, especially when concatenating the SKU variables. Either Select statements or another method that I am unaware of, could be the solution.
Thanks in advance for any and all suggestions and assistance.
EDIT: I hope this helps clarify. I would prefer to use this form
to complete the task. The checkboxes are not in an option group so they could all be checked if the user requires it. For the purposes of this question, let's assume the user has checked all the boxes. This would equal 10 total combinations.
I run this sub to generate a SKU based on the paper type and the print size:
Private Function UpdateArtwork()
Me.MerchandiseSKU = Me.cboArtworkID_A5A.Column(5) & _
Me.cboPrintTypeID_A5A.Column(2) & Me.cboPaperTypeID_A5A.Column(0) & _
Format(Me.cboPrintSizeID_A5A.Column(0), "00")
Call UpdateArtworkPic
End Function
I am trying to figure out how to write the code for the new form that allows all 10 SKU numbers to be generated and create 10 new records for Artwork_ID (Artwork table).
I think that the best way of doing this would be to create a new table, called tblArtworkSKU, which has the following fields:
ArtworkSKU_ID - Autonumber, primary key;
Artwork_ID - number, foreign key from the Artwork table;
PrintSize_ID - foreign key from the PrintSize table;
PrintType_ID - foreign key from the PrintType table;
ArtworkSKU - text.
You would then create a small continuous form based on this table, with PrintSize_ID and PrintType_ID selected through combo boxes. When you place this form onto the main form that you have, Access should automatically let you join on Artwork_ID to create a one-to-many relationship.
You could then use the AfterUpdate events of each combo box to create the SKU.
Regards,
Related
(I've made up the example below as it's clearer than going through my specific case.)
Suppose I have a form for a User, and that the underlying User table has a personality_traits field; an array of the user's personality traits. Is there a standard way in rails to create a drop-down list so that the user can pick any number of a selection of attributes (e.g., "easy-going", "fun-loving", "quick-tempered"), and have these ultimately feed into the personality_traits field as an array? If not, does anyone know of a particularly good method?
bootstrap multiselect will do what you're looking for
You are building an MVC5 EF6 application where the user will add musical albums. A musical album has artist, record label, and category foreign keys which are each represented my their own respective models. On the create album page, the user will select through a drop downs the record label, category and artist. What happens if that artist or record label hasn't been entered yet?
Does the user have to go to the artist or record label view to add it first, then go back to the album page to create the album? Is there a better way to optimize the user process flow?
I had considered using a UI accordion that would be in the album view which would have panels for the album, artist, record label and category models. The artist, record label and category panels would start collapsed. If the user selects "Other" in the drop down for the artist, record label, category , the respective panel would expand and give the user the opportunity to enter the necessary fields to create the record label on the fly. Is this a bad idea? Are there other options I haven't considered that make the process easy for the user?
There are really only two options here:
Let the input form allow a new entry for Record Label, etc. This opens up the possibility of course of duplicate entries (spelling, abbreviation, etc.)
Create another form(s) where you manage those foreign keys, allowing someone to add a new label, artist, etc. The same possibility of duplication exists, however you might be able to introduce some fuzzy logic to search for similar names when an entry is added.
Either of these methods could also incorporate moderation, forcing new entries to be vetted by you or by some other entity, but of course that takes time. The biggest factor for me in making that decision would be whether or not the users of the system could be trusted to make intelligent decisions. (ie find an existing name and use that rather than just keep duplicating)
As far as the design, that's highly preferential and doesn't really have a correct answer. The best solution there is to make a mock up and have someone unfamiliar with the project use the site and get their feedback, and make changes accordingly.
I am building an inventory tracking tool to help people track either unique items (one-offs - say a vintage T-Shirt) or groups of items (a T-shirt design where I have a quantity). The data structures will be very similar, so that:
**Item**
Title
Status (sold, for sale) <- right now this is a simple array
Location <- this is a relationship to a diff model
etc...
**Item Group**
Title
Quantity
Status ([quantity] sold, [quantity] for sale) <- this should be an hstore??
Locations ([quantity] location1, [quantity] location2) <- not sure about this yet!
etc...
I'm expecting to use different forms to gather this information, as too much complexity on the form to accommodate these differences will add difficulty for my user group.
So my questions are as follows:
What is the best data solution for this? Do I want to have two models/controllers or try to extend the Item model? How do people usually handle this sort of issue?
I do have the requirement that I need to show the user all of their inventory (items and groups) at once, but this seems the smaller task to me.
Reduce your headaches and don't differentiate between unique items and non-unique ( ie, all items have a quantity ).
Then you want a "purchace" model, and then a "item_purchace" model to act as a join table.
Following the layout here: guides.rubyonrails.org...
I'll try to be short and clear with this question.
We have an asp.net mvc app that uses entity framework 4.
Our business model is relatively straightforward:
We have an object (which corresponds to a table) called Photo(s).
That photos table has a handful of columns that match up to properties on the object.
Description,Title,Date etc.
It also has a number columns that reference foreign keys for other tables:
AuthorId,LicenseId etc...
The author and license tables are complex in their own right, with multiple fields (Title,Summary,Date etc.)
I have multiple clients using this application to view their photos. I would like each client to dictate what fields they see when viewing the photos, as well as what fields they see when editing those fields.
My thought is to have tables setup saying client-a should see Field1,Field2 and Field3 when viewing their photos - and client-b should see Field1,Field4 and Field5. But some of these fields are not simply columns in the main photos table, they may be fields in a child table. so Field1 might be: Table.Photos.Title -> which corresponds to an object as: Objects.Photo.title...
but Field3 might be: Table.Licenses.LicenseSummary -> which corresponds to an object as: Objects.Photo.License.LicenseSummary
I'm trying to figure out the methodology that we would use to have a very data driven environment so in the DB I can say, display this object/property (for viewing or editing) and then it would know how to map to whatever table it needs to pull that information. also, during editing... give it some way to pull a list of available values if it is that type of property, and not just a text field.
I'm looking for an example of what this might involve, our model is actually more complex than this, but this is just an idea of what we are trying to accomplish. I don't know if what I'm trying to do is normal, perhaps it involves reflection? This is a new area for me.
If the clients are defining their own custom fields, I would simply give them a Key/Value pairs table.
PhotoID FK
Key string
Value string
Display bool
Note that this essentially amounts to EAV, which comes with its own set of difficulties.
If it's just about permissions on existing fields, you need to capture that information:
PhotoID FK
ClientID FK
FieldName string
Display Bool
You can use this information to inhibit the display of fields in the View. The easiest way to do that would be to use a loop in the View itself, writing the field to the output only if Display is set to true.
I'm programming a website that allows users to post classified ads with detailed fields for different types of items they are selling. However, I have a question about the best database schema.
The site features many categories (eg. Cars, Computers, Cameras) and each category of ads have their own distinct fields. For example, Cars have attributes such as number of doors, make, model, and horsepower while Computers have attributes such as CPU, RAM, Motherboard Model, etc.
Now since they are all listings, I was thinking of a polymorphic approach, creating a parent LISTINGS table and a different child table for each of the different categories (COMPUTERS, CARS, CAMERAS). Each child table will have a listing_id that will link back to the LISTINGS TABLE. So when a listing is fetched, it would fetch a row from LISTINGS joined by the linked row in the associated child table.
LISTINGS
-listing_id
-user_id
-email_address
-date_created
-description
CARS
-car_id
-listing_id
-make
-model
-num_doors
-horsepower
COMPUTERS
-computer_id
-listing_id
-cpu
-ram
-motherboard_model
Now, is this schema a good design pattern or are there better ways to do this?
I considered single inheritance but quickly brushed off the thought because the table will get too large too quickly, but then another dilemma came to mind - if the user does a global search on all the listings, then that means I will have to query each child table separately. What happens if I have over 100 different categories, wouldn't it be inefficient?
I also thought of another approach where there is a master table (meta table) that defines the fields in each category and a field table that stores the field values of each listing, but would that go against database normalization?
How would sites like Kijiji do it?
Your database design is fine. No reason to change what you've got. I've seen the search done a few ways. One is to have your search stored procedure join all the tables you need to search across and index the columns to be searched. The second way I've seen it done which worked pretty well was to have a table that is only used for search which gets a copy of whatever fields that need to be searched. Then you would put triggers on those fields and update the search table.
They both have drawbacks but I preferred the first to the second.
EDIT
You need the following tables.
Categories
- Id
- Description
CategoriesListingsXref
- CategoryId
- ListingId
With this cross reference model you can join all your listings for a given category during search. Then add a little dynamic sql (because it's easier to understand) and build up your query to include the field(s) you want to search against and call execute on your query.
That's it.
EDIT 2
This seems to be a little bigger discussion that we can fin in these comment boxes. But, anything we would discuss can be understood by reading the following post.
http://www.sommarskog.se/dyn-search-2008.html
It is really complete and shows you more than 1 way of doing it with pro's and cons.
Good luck.
I think the design you have chosen will be good for the scenario you just described. Though I'm not sure if the sub class tables should have their own ID. Since a CAR is a Listing, it makes sense that the values are from the same "domain".
In the typical classified ads site, the data for an ad is written once and then is basically read-only. You can exploit this and store the data in a second set of tables that are more optimized for searching in just the way you want the users to search. Also, the search problem only really exists for a "general" search. Once the user picks a certain type of ad, you can switch to the sub class tables in order to do more advanced search (RAM > 4gb, cpu = overpowered).