I have a Skyve document and I want to allow the user to add a list of free form text items.
e.g
5m of electrical cables
T junction
5m conduit
is there a better way to model this than to have a new document with just a single text field?
Usually it makes sense to model lists as a new document as it will allow for the most flexible querying in subsequent functionality.
We have implemented use cases where we scatter and gather list contents into a memo field as comma separated values (CSV).
Skyve does not support this out of the box although we have planned to.
One way to implement this is to use an inline data grid bound to a non-persistent collection (maybe of admin.Generic) and perform the CSV transformations to a persistent memo field in the Document's Bizlet or in View Actions depending on the user interface requirements.
Keep in mind that a memo field is textually indexed by default, so it might be useful to turn that off for this use case.
Related
I'm currently creating a website for a local hospital. The problem I am currently facing: The website has too many checkboxes and fields that are enabled/disabled depending on the checkbox.
This is url to the website: http://ali.ezyro.com/adan/myForm.php
Since I have little experience with databases, what is the best way to design the database to hold all the data of this document?
This is a case where a relational database may not be your best option - it all depends on how the data is used within the system.
The straightforward option is to design one (very wide) table for each patient. Each attribute is modelled as a column; multi-valued attributes (check boxes) have one column for each valid option, single-valued attribute which require a lookup from a list of valid options use a foreign key to a table holding the valid lookups (e.g. in the patient table, you have a column called cervical_collar_id, and you have a separate table called cervical_collar_values with 1 - prehospital, 2-on arrival, 3-not required).
This allows you to store the data, and query it efficiently using standard SQL (find all patients who arrived with a prehospital cervical collar, for instance).
The "if you select box x, then box y becomes mandatory" logic should probably live in the application, not your schema.
But this is a difficult design to work with - adding attributes to the patient record is non-trivial. Wide tables are usually a bad sign.
You might decide that's a bad thing, and go for "entity/attribute/value" design. Lots of Stack Overflow answers will tell you the benefits and drawbacks of this - Google is your friend. TL;DR: even moderately complex queries become almost impossible.
You might instead decide to store the data as a document - most database engines store JSON and XML, and allow you to query this data efficiently. It has the benefit of being easier to develop, and easier to change - but you lose the built-in validation that the relational model gives you.
I have a program which grabs html, specifically quarterly reports from SEC.gov, using libcurl's WRITEFUNCTION to hold them in memory.
I now want to "read through" the HTML of the reports, storing many (many) desired values, basically anything in the financial or balance sheet tables. These would have identifying substrings within the document of various lengths.
Which (if any) of the following would be applicable here:
Boost::regex - search for a set of expressions and store next value found upon finding them
Libxml++ (or some equivalent) - form a DOM tree and write a method which traverses it's nodes, storing data when the node is of a certain type or contains a certain string ("Net Revenue" for example).
Or suggest some other library or methodology with the capability i'm looking for?
I'm working on an application that saves phone numbers, the mask for the phone number is (99) 9999-9999.
Should I save the whole string on the database. i.e.:
(99) 9999-9999
or just the data i.e.:
9999999999
and only format it in the UI?
I'm leading towards the second one but I couldn't give good reasons on why is that. My coleague argument was that the first one (the one with the mask) would be easier, since it's not necessary to apply the mask in different UIs (reports, webpage).
Separate data and presentation logic - this is good practice.
I suggest you to store only number, as number is data, and formatting is not (store only data in database).
Second, maybe for this moment you have 1 format, but believe me - in some time you will need another format and then you will have to re-format it (some kind of murphy's law)
Of course, for performance reasons you can cache visual presentation - create additional field(s) for it and use it for display, update it when main "data" field is updated
I have a web form with about 15 checkboxes that users may check 0 or all 15 checkboxes and any quantity in between. The database that will store the form data is MySQL, but reports will be generated from the data in MS Access using a MySQL ODBC connection. I see three options for handling this.
The Spreadsheet way:
Have one table with a boolean column for every checkbox and a text box for "Other"
The Normalized way:
Have two tables, one with the form data other then the checkbox info. Then a second table containing the FK of the form data and the value of the checkbox in a one to many relationship. Handle the inserting of the checkbox values separate from the insertion of the form data with some looping when the form is processed.
The Short way:
Have one table with a text field for the checkbox data. When processing the form concatenate checkbox values into a comma separated string and put that in the text field along with the other data.
Both the Access way and the Short way are enticing because of the ease in which they can be used to generate reports, the Short way especially. Unfortunately, while I prefer the normalized way no one in my organization who develops the Access parts knows how to generate reports that use the normalized data properly, at least not cleanly. Both The Access way and the Short way can be problematic when filtering by checkbox values (the Access way more so).
How should I proceed in this? If I go the normalized way I will also have to take responsibility for developing a tool to generate reports, which may step on a few toes and be a bit of a political wrangle. I stick with what they are using already (The Access way) increasing my immediate workload and buying myself a mess of programming problems down the line, but avoiding any office politics. Or the hybrid way which costs a bit of programming now and some annoyance later, has only a few obstacles in other project members?
I disagree that what you call "the Access way" is not normalized. As long as all the checkboxes have a different meaning, and are dependent only on the key (and not on each other), the table is normalized (at least, 3NF or BCNF).
In other words, if you don't see any trouble reporting with that structure, go ahead, Codd won't come and haunt you in your sleep. (And even Date will probably be ok with this, as long as you don't store "off" checkboxes as NULL :p)
If the true/false value are discrete pieces of data that are directly related to the PK then you could put them in the same table as the entity they are for.
If you wanted to separate it out into another table then that is fine. Just put a column for ever option. This is easy to expand or remove in the future by adding or removing columns.
I would not recommend the list of comma separated value because that is not as maintainable and leads to confusion.
Design your data to be captured in normalized form.
In your Access DB, build a Crosstab query that will display it in the format you described, with a separate column for each item of checkbox data. Use that crosstab query as the view from which people extracting data for reports make their selections.
You get the best of both worlds, at the expense of spending some time performing the crosstab query. If this delay gets to be exhorbitant, consider snapshots.
I understand the maximum number of fields in a MS-Access form is 255. Is there any way to get around this limitation?
I am working with a mental health survey form that has approximately 400 fields.
I would like to create 1 data entry form to allow the mental health interviewer to enter all the responses on the one form.
I plan to use tabs to facilitate moving through the data entry.
The maximum number of fields in an Access recordsource is 255, as is the case with any Jet SQL statement. The limitation on the number of controls on a form is 754 over the life of the form (i.e., deleting a control does not gain you an additional control).
The design is clearly not correct, but as is so often the case, we don't get to choose on these things!
In that case, the only solution I can think of is a main form that has one field, the PK, and then a bunch of subforms with subsets of fields, e.g., 100 each. This means you have to be very careful about making sure that your subform saves its edits in its OnExit event (otherwise you'll get write conflicts).
And, no, it's not a good design at all.
But it is, at least, a workaround if you're forced to have 400 fields because you have an outside datasource that you can't properly normalize.