I am still on the way to learning Django.
I am going to create an app. That would essentially be an instant financial ratios calculator. Which would comprise of various forms (say like Loan calculations, Mortgage calculations, interest calculations, etc, etc. one field from one form(Loan calculator) would also be part of other single or multiple forms. The target (field on another form) will need to be instantly updated as the user is updating the inputs on the form
Using the typical approach of forms and views (that will essentially bind to HTTP [get/post]).
I am looking for a way to have the field (derived from one field) updated instantly as soon as an input is received from the user.
The basic example is here
https://html.form.guide/calculation-forms/simple-html-calculation-form/
I am keen to use Django, what do you guys suggest would be the best approach to undertaking the above-mentioned tasks and at the same time satisfying the instant field update criterion as in the link above?
Looking for some guidance.
The task you mentioned is more like frontend stuff. You should use javascript.
Related
I want to build a small Access database to better keep track of the companies we are looking at. I read Access 2010 Inside Out by Conrad/Viescas, did a lot of their examples and had the feeling I understood the basics, so I started with my own data base. Now the struggle begins, I think I have a basic misunderstanding here.
The relation I started with is quite simple: Each company we look at can have listed peers that we want to use to compare this company to. Of course, each company can have many peers and each peer can be the peer of many of our companies. So I modelled this relation as a many-to-many relationship:
Next, I created the form for a company, which looked something like this:
I related the subform I used to show the peers with a query that is based on tblPeersCompanies_1 and gives some additional information. What I now want from a user perspective is straightforward: A user should simply add peers to this subform for the company he is currently viewing. Access should then automatically update tblPeersCompanies_1 and tblPeers_1. The peers really serve no other purpose than to relate them to a company.
However, I struggle implementing this. Adding a new peer to the subform does not work, simply because it is not based on tblPeers_1 and if I enter the information there, Access notices that the peer is not in that table yet. (That is at least what I think the problem is). How can this be achieved though? I don't want the user to open another form, enter the peer first, go back to this form, type the peer again and the other related information. I hope that there must a simple way to do that automatically. Or is this indeed not so simple.
In summary, the question probably can be phrased as: "How to add records to a matching table and a related one-table on the fly in a form?"
Thanks to the great comment by #Remou, I found a solution to this problem. It contais three steps:
Use a combo box as outlined in another SO post
Use this function to automatically enter new records in case the peer is missing. Call this function in the "On Not in List" event
Show other values from tblPeers by linking it to the selected value in the combo box, as explained here
I have to say, this is much harder than I hoped it to be. Let's hope that the learning curve is steep and that it will at least be easy to use for the user and quite robust.
I am working on project in economy where I need to manage large data in linked tables, with many foreign keys.
I have a few years of experience as Oracle DBA so I can manage all that without problem,
But I need to be able to share the data with others that have no knowledge in databasing,
There for I need to get them some graphic way to show the data.
Toad does all what I need and much more, but the program is too complicated for my needs.
Instead of wasting time on writing a program in C# that manages the data, I am looking for a good program that:
Shows Main table/view data with option to filter/group/order with drop-box options
Selects a row and shows data in linked tables by the selected row's data
Makes report/data pages of my selected rows that I can adjust and print. (I know it's a bigger request)
In Addition, what is the most fit and easy DB for it? I worked only with Oracle but it's sure too much for that, so MySql? Access (I tried first to do all that in Access program but It's just too hard to adjust forms and so, and in the end you cannot make a publish version.
And the tables will be with start_date and finish_date that follow each other for same ID,
But I don't think it will be a problem that I can maximum make view that shows only the last one. (BTW, what is the name of such table, I never knew that)
Take a look at Tableau http://www.tableausoftware.com
It will let users view the data many different ways, makes great visualizations and works with most databases. It's a read-only tool, so it's perfect for safe reporting, but you'll need to couple it with something else if you want your users to make changes to the data.
You can define a connection in Tableau that sets up the relationships for users that don't understand foreign keys and the like. Or make views that hide those details, of course, regardless of the tool you choose.
Does anyone have any pointers on how to go about creating a "wizard interface" using Access 2010? I need a sequential set of forms that will be capable of branching the flow based on answers from the user and data found in the database. I have used Access before for some CRUD/Reports type of applications, but in this case I can't seem to wrap my head around how to get started on such a complex machine.
Before anyone suggests it, I cannot use anything but Access due to client requirements.
I feel your pain ... working with Access gets so difficult where there are complex requirements.
Gather and document the requirements
Make sure you've teased out every possible wrinkle and contingency from the client, and put it into a flow chart or something.
Extract the models
Figure out what models are being used -- customers, addresses, vendors, products, etc. These will have to be created as tables or adapted to existing ones.
Extract other variables
What could potentially change over time and/or what will the client want to be able to change via an admin screen? You'll have to decide which of these variables to put into tables, and which are ok in the code (form logic and/or VBA).
Design the tables for the wizard views
I imagine you'll want a wizard screens table, where each row corresponds to a step; each should have (other than an id column) a previous screen column, and a form name or form template name column. You'll need a second table choices with a many-to-one foreign key linking back to screens; each row here will correspond to a possible outcome of the view, and the target next step in the wizard.
Design the forms
Finally, design the forms corresponding to each wizard step or template, pulling data from the structures in 1-4 as needed.
I have a web application that uses a relational database (MySQL). We're adding a new feature that will allow certain users to dynamically construct 'forms' from a pool of optional form elements and distribute these forms for completion/submission to other users.
The problem lies in storing the completed form submissions. Each form can and will vary in the number and combination of form elements, and with a relational database my options are somewhat limited to dynamically creating a new table to hold the submissions of each form (seems like a bad path to go down) or storing each of the submitted forms as JSON in a TEXT column (losing all useful querying abilities of RDBMSs)
I've never actually used MongoDB in a production project before, but I'm thinking it might be a good idea to use my MySQL relational database to store all the forms created by certain users of my application, and then store all the submissions in MongoDB with each document referencing the UUID of the form in MySQL.
The first disadvantage I can think of with this approach is there's no referential integrity between form submissions and the forms located in MySQL. If I delete a form in MySQL, all of the form submissions will have to be manually deleted (if I want to replicate the 'Cascade' effect)
Would I store all of my form submissions for all of my forms in a single MongoDB collection as individual documents? Any advice is greatly appreciated. :)
EDIT 1
Based on the documentation here: http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections
I'm now considering creating a new collection to hold all the submissions from each unique form type.
EDIT 2
After some careful consideration and the advice of others I've decided to abandon my dual-database approach to solving this problem in favor of a relational-database schema that I think solves the problem of creating dynamic forms and saving the form submissions in such a way that they're easily query-able for complex reporting.
Essentially every record in 'forms' represents a unique form that was built by a user. 'forms_fields' has a foreign key that references the form and an enum-type with the options:
1. checkbox
2. textfield
3. textarea
4. select
5. multi-select
6. date
'forms_fields_options' contains all of the 'options' a select field would have.
With these three tables, users can create customized forms.
When another user fills out & submits the form, a record is created in forms_submissions. For each field, a corresponding record will be created in 'forms_submissions_fields' that references the form submission and the forms_fields_id. The final table, 'forms_submissions_options_multiselect' is essentially a join-table to indicate which options from a multi-select form field the user selected.
A colleague of mine recently lead a webinar on just this subject, titled "Hybrid Applications with MongoDB and RDBMS". You can view it here:
http://www.10gen.com/events/hybrid-applications
From the comments, it looks as though you have already decided to go the RDBMS route, but hopefully this can give you some ideas for a future project, or be beneficial to someone else reading this thread.
Good luck with your application!
This can definitely be done in SQL using EAV. So NoSQL is definitely not required.
Using a tool like MongoDB could be a good fit for the flexible results you want to save, however, there are some trade-offs here, but they may not be exactly what you're expecting.
... storing each of the submitted forms as JSON in a TEXT column (losing all useful querying abilities of RDBMSs)
How many form submissions are you planning to have? What type of querying are you planning to do?
My experience with MongoDB is that it performs very poorly when you're querying against data that is not indexed. In addition, aggregation is generally done in batches using Map/Reduce (or the new Aggregation Framework).
If you compare the complexity of doing roll-ups or the efficiency of doing queries, it's not clear that MongoDB is significantly better here than EAV.
If I delete a form in MySQL, all of the form submissions will have to be manually deleted
Oddly, I have rarely seen this as a problem as you will probably never delete the form in SQL. you will likely do a logical delete and never really remove anything. So this is probably a moot point.
Would I store all of my form submissions for all of my forms in a single MongoDB collection as individual documents?
Again depends on how many forms and submissions you're planning to get. If you have lots of both, then using a collection / submission is going to be very difficult to shard later on.
Honestly, I would use a single collection and then override the _id field to something that can reasonably be used as a shard key. There are some fancy tricks you can play here, but that's beyond the scope of this little write-up.
Summary
End of the day, you can definitely use MongoDB for this problem, but it's not a "home run". If you are unfamiliar with MongoDB, this is definitely a fair "learning project", but expect to hit some roadblocks around querying and aggregation.
I think you're overlooking the fact that an RDBMS will allow things like EAV (Entity-Attribute-Value, which is horrid if you overuse it, but can be great in moderation) or join tables, to construct multiple ordered relations from a single form to various form elements.
I'm not suggesting that an RDBMS is perfect for everything, or even your situation, but I know I have had to build similar systems and have never had to go noSQL to support them in a reasonable way.
Edit: More to the point... storing actual field values puts you one more relation out from the original form elements, but if your UI keeps things consistent you can do this generically. I'd say looking further into which noSQL solutions allow the particular kinds of value-based querying you need might shed more light on your options.
I am trying to build a user interface which will allow users to choose what kind of information they want, then based on these selected conditions, I need to query an access database and retrieve the corresponding data for future calculation. During calculation, there are two additional tables that I will query from. Finally, I need to display the calculated results to users. Now I have some questions:
Which one will be easier if I use excel as a front-end to users and retrieve querying data from Access to excel vs. I use access forms as a front-end to users and directly work with access to query data?
Does access forms can perform functions like allow users to select options from a drop down list? and once options selected, Access will query the target info?
Can Access perform intermediate calculation for large amount records? Will it get very slow? Compared to excel, which one is better in terms of calculation?
I never use Access before and just know a little about Excel VBA, not totally familiar with it, not to mention object models. So, in this case, which way is time-saving for me? or they are probably the same time-consuming?
Anything else that I should be aware of?
Thanks so much!
Bing
Definitely Access - it is specifically made for working with, querying, and reporting on data. The language of VBA that you have experience with in Excel is the exact same language used for coding in MS Access!
Access, no question!
Absolutely. Of course it doesn't magically know this as your requirement. You have to drop the combo box on the form yourself, and then in the OnChange event of the combo box, alter a query statement that displays results to filter based on the user's selection.
Sure. Make a temp table (a table that is only used for the calculation), populate the records with INSERT statements, apply intermediate calculations with UPDATE statements, and display the results. Access is built for this kind of thing and will most likely be faster than Excel.
Access uses VBA as well. There may be a larger learning curve to switch, but if you are familiar with the user interface objects in Excel such as Button, Combo Box, etc., they will be very similar and yet more intuitive in Access (Because that's what Access was made for)
Access has some quirks. Google a few tutorials and get some background on the ways Access is traditionally used for your kinds of scenarios and it will go a long way toward streamlining your development.
Start with the simplest model that will accomplish what your requirements are, and implement it. Then work through the quirks and bugs that you find with Google as your friend, and you should be able to get something solid pretty quickly! As you get into the experience, feel free to post new questions with specific problems you find along the way.
Best Regards,