I have a database in Microsoft Access 2007-2010. It's set up in 4 tables:
A list of machines, each with an identifying number
A list of parts, each with an identifying number, and a number that corresponds to the machine it is on
A list of problems, each with an identifying number, and a number that corresponds to the part it occurs on
A list of solutions, with a number that corresponds to the problem it solves and multiple fields for various information about that solution
I want to create a form that will allow you to chose a machine, then either chose an existing part or add a new part from that machine, add a new problem, or chose an existing problem, if an existing part was found, and finally add a new solution, and all the fields related to it.
I'm very inexperienced with Access, so I have no idea how to do this. Any help will be much appreciated.
As user Beth suggested, subforms are designed for this type of problem. Simply create a form for each 'Level' and nest them. You need to link each form to the parent form above it by using the child properties 'Link Master Fields' and 'Link Child Fields', this is where you would link the top level MachineID from the Machine table with the next Level MachineID from the Parts table.
The question you pose is a little too broad to really be answered here, so you are best off looking at something like This link and then coming back here to ask questions about specific problems you are having with your implementation.
Best of luck!
Related
This is a fundamental novice level question that will not be short. This is specific to Backendless.
I have a number of scenarios I would like to be able to address, as I am working with a small set of tables that are all interrelated in some form and need to be explored from various directions.
A basic example would be something like PersonTable and AddressTable. PersonTable containing a list of people, with their lastName, firstName, etc. AddressTable containing addresses and their various attributes of streetName, houseNumber, etc.
Let's say I want to provide users two distinct views in a main navigation and allow them to drill down further.
View1: You click "People", you get a list of people from the PersonTable. This list appears in a secondary navigation window. Clicking an individual person will provide you the address/addresses associated with that person.
However, I also want to be able to do this in reverse:
View2: You click "Address", you get a list of addresses from the AddressTable. This list appears in a secondary navigation window. Clicking an individual address will provide you with a person/people associated with that address.
So from a uni-directional approach, there would be a relationship from PeopleTable to AddressTable. This is perfectly well and good for View 1. One query will provide the data for the secondary navigation and the results from that query can include the relationship data needed for the drill down.
However, if I wanted to support View 2, I would have to perform two queries given the direction of the relationship and where I am starting.
If you scale this to a larger set of data with more tables and fields, my concern might become more apparent. Because I want to actually provide some data from the parent of the relationship in the initial secondary navigation item creation. So that means an initial query of that table to list the items, and a query for each individual item (to obtain the data I need from it's parent in the relationship) to complete the data shown in the initial list. (Then clicking an item would provide even more detail). Obviously this relationship can be reversed, and I would then be pulling child data and not parent data, but then when I want to come at the data from the other direction (the other View) I am in the same situation again.
TL;DR: I need to be able to traverse tables in pretty much any direction and drill into data while attempting to minimize the number of queries required to do so for any given case. Is this a case where a large number of relationships is warranted?
Getting to the root of the question: My understanding is that, while Backendless does support them, bi-directional relationships are generally frowned upon (at least in the SQL world).
So, really, what is best practice? Is it simply a logical "Create relationships when they help you reduce queries"?
Bidirectional is frowned upon here too, though it does work. You may find a few bugs as it isn't used much.
The reason is that it isn't required, you already know you can make a request to get the inverse content.
But, the reason you should not use them is that auto-loading all of that extra data when you might not use it is more costly than making explicit requests when you do...
Also, you can limit your query impact in terms of network traffic by creating a custom service which does all the leg work.
However, if I wanted to support View 2, I would have to perform two
queries given the direction of the relationship and where I am
starting.
Performing two queries is not necessarily in Backendless, as the query syntax supports "backward lookup". It means knowing a "child" object, you can lookup its parent using the following syntax of the "whereClause":
childRelation.objectId = 'childObjectId'
For example for your Person and Address tables, suppose the relation column in the Parent table is called "addresses" and it is a one-to-many relation. Then the query sent to the Person table is:
addresses.objectId = 'specific-objectId-value-from-Address'
Keep in mind that you can test your whereClause queries using Backendless console. Here's an article about that feature:
https://backendless.com/feature-14-sql-based-search-for-data-objects-using-console/
Hope this helps.
I have two database tables where there is a one to many relationship. I would like to show the data via model-view architecture in Qt where one clicks the plus sign on the view and the rest of the relational data is displayed below. What is the better way of implementing this? Will QTreeView or QSQLRelationalModel be sufficient for this implementation?
Thx in advance
I conducted some search as to the better implementation of this case, and I was able to display two seperate tables via QStandardItemModel and QTreeView.
For columns that do not match I just left blank and I increased the number of columns in QStandardItemModel so that it includes the desired columns from both tables.
I thought the information might be useful for those looking for an answer for this question.
Sincerely
P.S. My points were decreased by 2 points for this question. I just wonder why my points are decreased for asking a question.
I'm trying to write a REST interface for an application.
The Model
In the model of this application I already have a situation like the following:
A person can have multiple activities.
An activity can be referred by several people.
The activities of the people are ordered with a specific field (position).
I've represented this situation in my db with three tables: people, activities, people_activities. The table people_activities features three fields: person_id, activity_id, position.
The new Requirement
Everything worked fine until now but now I've got a new requirement, I should be able to insert an activity for a person on top of the others.
So if the content of the people_activities table is for instance this one:
"mark reading 0"
"mark running 1"
if I received the request to add "mark juggling" the result should be:
"mark juggling 0"
"mark reading 1"
"mark running 2"
The solutions
The dilemma for the REST interface now comes from the fact that I identify only two options:
using a single URL like /people/mark/addActivity but this doesn't seem restful at all since it modifies resources not referred by the URL and contains a "verb" too much.
using some URLs like what I'm already using (something like /people/mark/activities or /people_activities?person=mark) and post the new change towards all these resources. This seems to be restful but very sloppy in my opinion.
What's the proper way to deal with this situation in your opinion? Is there a third option I'm not considering?
First Edit
Just by thinking better about the questions I'm realizing that another reasonable solution would be to end with this situation in the database:
"mark juggling -1"
"mark reading 0"
"mark running 1"
Because the position is just a number that has not a "real" value for me. In practice I cannot do that but it looked like a precious information and a way to add a new resource without modifying the other associations, that is not something i need to do from my business logic point of view.
Maybe another error is that I'm letting to much database data spilling on my interface. In this case what i really need from a business perspective is the order of the elements, not their position. The position thing is just a technical detail I have used in the database to accomplish the ordering.
So another question maybe:
is reasonable in your opinion to modify some information in your database if this information is just a technical detail and it's not exposed to the interface users?
I think your solution of inserting the new entity with a position of min(position) - 1 sounds good.
We are also looking to build a RESTful API backed by a SQL database that allows the resources to be reordered and have faced this problem with the implementation details of how to add a new entry to the start or in the middle of the list without having to update the positions in all the entities.
In our implementation we plan use a floating point number for the position field and plan to follow these rules:
If the user wants to insert the entity to the start of the list, insert with a position of min(position) - 1.0
If the user wants to insert the entity to the end of the list, insert with a position of max(position) + 1.0
If the user wants to insert the entity anywhere else, insert with a position equal to the average of the positions of the two entities either side.
With the technology we are using we get 1073 inserts between two entities before we need to rebalance, by updating the position fields in all the entities to be all spaced 1.0 apart from each other. This is fine for our use case.
Side note: With a graph database you don't have this problem. It is very easy to add a new entity anywhere within the list by just updating the two relationships of the nodes either side, just like when you insert something into a Linked List. So that is something else to consider if you are not tied to a SQL database
All of the above is implementation details. With regards to how the API should look to an end user, I would vote to make it appear however is easiest for your clients. In our use case I hope for us to make the position field appear as a 0 based integer index (just like an array), as that will be easiest for our clients. This would mean that inserting a new entity at the beginning of the list will make it appear that the position field in all the other entities has changed, but I think that is fine. It doesn't fly in the face of the REST philosophy too much. It's pragmatic.
Hi I am trying to design a database for an e-commerce website but I can't seem to find a way to do this right, this is what I have so far:
The problem appears at the products.I have 66 types of products most of them having different fields.I have to id's but both of them don't seem very practical:
OPTION A:
At first I thought I to make a table for each product type, but that would result in 66 tables which is not very easy to maintain. I already started to do that I created the Product_Notebook and Product_NotebookBag tables. And then I stopped and thought about it a bit and this solution is not very good.
OPTION B
After thinking about it a bit more I came up with option B which is storing the data into a separate field called description. For example:
"Color : Red & Compatibility : 15.6 & CPU : Intel"
In this approach I could take the string and manipulate it after retrieving it from the database.
I know this approach is also not a very good idea, that's why I am asking for a more practical approach.
See my answer to this question here on Stack Overflow. For your situation I recommend using Entity Attribute Value (EAV).
As I explain in the linked answer, EAV is to be avoided almost all of the time for many good reasons. However, tracking product attributes for an online catalog is one application where the problems with EAV are minimal and the benefits are extensive.
Simply create a ProductProperties table and put all the possible fields there. (You can actually just add more fields to your Products table)
Then, when you list your products, just use the fields you need.
Surely, there are many fields in common as well.
By the way, if you're thinking of storing the data in array (option B?) you'll regret it later. You won't be able to easily sort your table that way.
Also, that option will make it hard to find a particular item by a specific characteristic.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have a question about best practices regarding how one should approach storing complex workflow states for processing tasks in a database. I've been looking online to no avail, so I figured I'd ask the community what they thought was best.
This question comes out of the same "BoxItem" example I gave in a prior question. This "BoxItem" is being tracked in my system as various tasks are performed on it. The task may take place over several days and with human interaction, so the state of the BoxItem must be persisted. Who did the task (if applicable), and when the task was done must also be tracked.
At first, I approached this by adding three fields to the "BoxItems" table for every human-interactive task that needed to be done:
IsTaskNameComplete
DateTaskNameComplete
UserTaskNameComplete
This worked when the workflow was simple... but now that it has grown to a complex process (> 10 possible human interactions in the flow... about half of which are optional, and may or may not be done for the BoxItem, which resulted in me beginning to add "DoTaskName" fields as well for those optional tasks), I've found that what should've been a simple table now has 40 or so field devoted entirely to the retaining of this state information.
I find myself asking if there isn't a better way to do it... but I'm at a loss.
My first thought was to make a generic "BoxItemTasks" table which defined the tasks that may be done on a given box, but I still would need to save the Date and User information individually, so it didn't really help.
My second thought was that perhaps it didn't matter, and I shouldn't worry if this table has 40 or more fields devoted to state retaining... and maybe I'm just being paranoid. But it feels like that's a lot of information to retain.
Anyways, I'm at a loss as far as what a third option might be, or if one of the two options above is actually reasonable. I can see this workflow potentially getting even more complex in the future, and for each new task I'm going to need to add 3-4 fields just to support the tracking of it... it feels like it's spiraling out of control.
What would you do in this situation?
I should note that this is maintenance of an existing system, one that was built without an ORM, so I can't just leave it up to the ORM to take care of it.
EDIT:
Kev, are you talking about doing something like this:
BoxItems
(PK) BoxItemID
(Other irrelevant stuff)
BoxItemActions
(PK) BoxItemID
(PK) BoxItemTaskID
IsCompleted
DateCompleted
UserCompleted
BoxItemTasks
(PK) TaskType
Description (if even necessary)
Hmm... that would work... it would represent a need to change how I currently approach doing SQL Queries to see which items are in what state, but in the long term something like this looks like it would work better (without having to make a fundamental design change like the Serialization idea represents... though if I had the time, I'd like to do it that way I think.).
So is this what you were mentioning Kin, or am I off on it?
EDIT: Ah, I see your idea as well with the "Last Action" to determine the current state... I like it! I think that might work for me... I might have to change it up a little bit (because at some point tasks happen concurrently), but the idea seems like a good one!
EDIT FINAL: So in summation, if anyone else is looking this up in the future with the same question... it sounds like the serialization approach would be useful if your system has the information pre-loaded into some interface where it's queryable (i.e. not directly calling the database itself, as the ad-hoc system I'm working on does), but if you don't have that, the additional tables idea seems like it should work well! Thank you all for your responses!
If I'm understanding correctly, I would add the BoxItemTasks table (just an enumeration table, right?), then a BoxItemActions table with foreign keys to BoxItems and to BoxItemTasks for what type of task it is. If you want to make it so that a particular task can only be performed once on a particular box item, just make the (Items + Tasks) pair of columns be the primary key of BoxItemActions.
(You laid it out much better than I did, and kudos for correctly interpreting what I was saying. What you wrote is exactly what I was picturing.)
As for determining the current state, you could write a trigger on BoxItemActions that updates a single column BoxItems.LastAction. For concurrent actions, your trigger could just have special cases to decide which action takes recency.
As the previous answer suggested, I would break your table into several.
BoxItemActions, containing a list of actions that the work flow needs to go through, created each time a BoxItem is created. In this table, you can track the detailed dates \ times \ users of when each task was completed.
With this type of application, knowing where the Box is to go next can get quite tricky, so having a 'Map' of the remaining steps for the Box will prove quite helpful. As well, this table can group like crazy, hundreds of rows per box, and it will still be very easy to query.
It also makes it possible to have 'different paths' that can easily be changed. A master data table of 'paths' through the work flow is one solution, where as each box is created, the user has to select which 'path' the box will follow. Or you could set up so that when the user creates the box, they select tasks are required for this particular box. Depends on our business problem.
How about a hybrid of the serialization and the database models. Have an XML document that serves as your master workflow document, containing a node for each step with attributes and elements that detail it's name, order in the process, conditions for whether it's optional or not, etc. Most importantly each step node can have a unique step id.
Then in your database you have a simple two table structure. The BoxItems table stores your basic BoxItem data. Then a BoxItemActions table much like in the solution you marked as the answer.
It's essentially similar to the solution accepted as the answer, but instead of a BoxItemTasks table to store the master list of tasks, you use an XML document that allows for some more flexibility for the actual workflow definition.
For what it's worth, in BizTalk they "dehydrate" long-running message patterns (workflows and the like) by binary serializing them to the database.
I think I would serialize the Workflow object to XML and store in the database with an ID column. It may be more difficult to report on, but it sounds like it may work in your case.