Humanipro application

[MarlonVisser0408]

I'm not arguing with that per se but even Excel has a "data type" although it is fluid. That is my objection to it. Why bother with a data type if you can put any ol' crap in the cell?

One does not need knowledge to put something in a excel cell. It's a good way to solve skill issues.

 

[CJ_London]

Other issues with excel - 1 million row limit and no indexing

 

[MarlonVisser0408]

I think I just might open up a seperate topic. There's much for me to learn and when asking questions related to it, it might as well be there - to keep on topic with the post.

 

[The_Doc_Man]

I think I just might open up a seperate topic. There's much for me to learn and when asking questions related to it, it might as well be there - to keep on topic with the post.

It might help keep the discussions about different issues separate so that they will be less likely to get all tangled with each other. And we don't charge by the thread count.

 

[LarryE]

I think I just might open up a seperate topic. There's much for me to learn and when asking questions related to it, it might as well be there - to keep on topic with the post.

3 things what would help us help you is to:

1. Describe the business or operations you are in and what kinds of things you want to keep track of (for example, we are wholesalers and want to track vendor purchase orders, customer orders and inventory levels or we are a sports club and wish to track memberships and payments etc.)
2. Take a screenshot of just the Headings and only the first row of your spreadsheet. You can delete any names, addresses or other confidential information (we don't need that). That will give us some sense of what kinds of data needs to be included in your ACCESS application. This will be useful for converting your current data to ACCESS tables.
3. Tell us how many users are going to use the application. ACCESS can accommodate multiple users, but only under certain conditions.

Before we consider each individual tree, we need to see the whole forest first. Unlike with EXCEL, you will be building a house with the table and relationship structure as a foundation. That comes first. Then you build the walls and roof.

As you must know by now, in ACCESS, you keep each piece of data in only one place and then connect different tables together. It's a whole different way of thinking so, fasten your seatbelt. But if you start by designing your data tables properly from the beginning, you can be sure the rest will be much easier.

 

[MarlonVisser0408]

[BEFORE YOU READ]: As mentioned before: I don't really have too much experience in coding or Access (yet). I'll be editing a few of the points here as we go through, so that it becomes a better explanation of what I'm trying to do. When I got a decent page done, I'll transfer this to it's own post so that maybe I can apply your generous help a little better.

What I just wrote down below is only a part of the information that I'm solving. However, I think if I handle these points below; I'll be a lot further in understanding in how to explain some of the things to you guys or that I'm already able to do parts myself from the earlier advice.

---

- Application use: The application is for humanitarian work. We're mostly active as management and coordination on refugee shelters. This is why there's a lot of different sorts of data, but almost no data will become very tall. This is the reason that a good interface or application is needed to both connect and properly edit the data on the fly. I'll give an example of some of the datasets and documentation that we're using to do our daily jobs.

---

Startscreen & Permissions:
- Even though the real security isn't through the application itself but rather by your access to the application, I like the idea of having a start screen with a standard login function. This will serve on application level as a filter for what you're able to see and do in the application. After the first modal page, if you have more then 1 function to your name; you will have another modal page that will ask you to which part of the application you want to sign in.

This is mainly because someone doing sales for the company shouldn't have any access to logs made at a shelter. At the same time, a coordinator that is working on a shelter, should not have the permission to look at financial or employee information when looking up his colleague in the Contact Relation Manager (CRM). At the same time, I want someone with serious access to be able to see everything that's regarding a entity in the application.

A quick snapshot from a User Record Page to look at how I can use the real-estate and to get a clearer picture of what I need to learn and do.

For reference:
- Record options will hold options like; 'resend password' or 'resend username' to the user their Humanipro e-mail.
- Record information will show information that's not really used by anyone other then someone working informatics or me/us. Think about UserID, PersonID.

I don't know what I'm doing sometimes, we have to start somewhere.. I guess somewhere is where you leave blanks for when you got more knowledge and experience to use this real-estate. The header and menu are simply there for referencing the real-estate made available for things like a navigational menu, header and the like. Patience, I can only fail at one thing at a time.

---

Contact Relation Manager:
- PersonID: This is just your average place of a contactbook. There's a few things that we need to add though; allergies (we sometimes provide food), 'emergency contacts' that I've added for now as a really (bad &) basic genealogy that adds phonenumbers. The visual below will show you more about what I mean.

- CompanyID: It's basically the same thing as the PersonID - just for companies. When looking up a company, I want to be able to see who works where and which departments. It'll show the information from the department.

As a quick visual to what I mean. All the information goes to a record where I can edit it all on the fly.

- AdressID: The AddressID will hold all the information that come together at an address. There can be multiple stakeholders, organizations and volunteers working at different locations and in different functions. To make sure that we don't have to deal with all that mess, the AddressID will act somewhat like a filter [I hope this makes sense] so that we have a page that will show only the things regarding an address.
- ShelterID: The ShelterID is the only one that I would point out is not a universal ID. That's my inexperienced way of saying that the other ones I can imagine are being used in many datasets, where this one I consider to be a 'custom ID'; somewhere I need to watch out for how I name things. The basic of it is that it's almost the same as AddressID. The difference here is that these are addresses that we work on. They'll hold a lot more information that is dependent on your permissions.
- ResidentID: For looking up residents that have been within our care.
- EmployeeID: The employee record will hold the information that we need to automatically generate the contract and documentation that is needed to work for the company. It'll also hold all the data the finances and HR need to do their work. This will also be the part where a employee can edit some of the details for themselves, like address, certificate numbers and the like.

[*Still need to solve groups.. We often use a group mail or a location phone tied to a function. So I'd like a way to add people to add group and for it to show up on the records with the appropriate list of people having access to that e-mail group. I like to see on forehand who that I'm talking to]

---

Logbook & activity tracker
There needs to be a general logbook page that you can use to make rapports and filter logs based on things like ResidentID, PersonID, CompanyID and the like. This way, we can make a full rapport about at what point of the process they are. These can be safety rapports about misbehavior to the Government branch that goes about this or it'll hold data for appointments that we made for them like the dentist or doctor. All information should be go down there so that we're able to make it convertible to PDF or able to being send by email.

This will mean that all the different little logbooks are linked with this badboy. This is so that we can use the UserPermissions in combination with who's being logged on to what function to give them an impression on how things look. You can check up on the activities of a complete shelter in 2 clicks to then be able to go to a resident or employee in an efficient manner.

[I haven't looked into the ability to hook up third party applications with this - but having outlook, whatsapp and/or (company)phone records being added automatically would absolutely make my year.]

 

[MarlonVisser0408]

---

Agenda
The agenda page is filtered in a few core points that we can filter on, because we'll use the agenda in different ways. Points being linked to ID's will also come back at the logbook. If you lookup a company, you can not only see the logs of what you've been doing; but also the things that still need to be done.
- Informational: On the core page, we'll show the informational part of the agenda. It'll show what the upcoming vacations are for the school going children, what the birthdays are and what religious holidays are coming up.
- Company: These are appointments made by the company. These can include company meetings or evaluations for example
- Shelter: All the information that is bound to you by your activities on a shelter. Because of European privacy laws, it's important that I try my absolute best and nothing less to secure this kind of data from the view of others - and it's the polite thing to do. It can include things like planning, tasks and appointments.
- Personal: This will include your own planning, appointments and free days.

---

Inventory
- Current Inventory: The inventory needs to go on a few different levels. We should be able to see it from a company standpoint, where a car is part of the inventory and as a shelter viewpoint; where I can check what the current inventory is; where did that 20 bread go?
- Inventory tracker: The inventory should be trackable. Where is an item at the moment (in case of company level) or to see where a product went. When we give out items to our residents, we're obliged to write down to who we gave what and when (you're only allowed X amount in the week kind of deal). This should be logged and tracked.
- Tracking amounts: There should be a form that lists the inventory that needs to be rebought. If we go over the minimum threshold of X, then buy up to the amount of X.
- Tracking expiring dates: Dates for both medical items and catering should be noted according to law. We should so in document in how we take care of the laws concerning expiring dates
- Catering inventory: To make things easy, we often help with taking care of produce of the catering or do a self-catering with the residents. This means that we hold stock of all the ingredients, gear and produce of the complete catering (for 50-300 people that come from 20+ nationalities per location). This means that we also need to keep data that shows if items are Haram for example or are using ingredients that someone could be allergic though. We use stickers for those items.

As expected; like almost everything, this needs to go back into the logging system. This way, we can see the things that residents already got or borrowed from us.

---

School, activities, sports & events
Despite promises and laws, the process of asylum often taken multiple years. For the first half year, one of is not allowed to work; there's no numbers yet that verify that you are you. Often this is even longer, which is only a step of the process that one needs to take. One of the core problems in the asylum is that people are bored out of their mind and have a lot of time to think about reasons they fled, things that are happening in the places they rather be or insecurities of having to go through years of process which by no stretch of the imagination is a guarantee.

There's many different opinions about how to make for a humane shelter location to spend years in and I'm a firm believer that someone needs to be able to participate in activities. sport and play. This is why I need to find a system that will allow me to make it easier to inventories what people want to do and to quickly get the right information and documents that match the activity.

It sounds easy, to do activities. I can tell you that it takes weeks for us to be able to play a normal game of basketball that looks like it's basketball. With people from 12 to 50 from 20 nationalities playing a game of which no-one really knows the rules about is tough. We often get the rules on documents, translate it and distribute it manually before we go and do something. The amount of time that goes into this makes my soul cry, I'm pretty sure that if we got everything done; creating a interface that works with this should be doable.

I don't really have too many concrete examples here, because there's only so much that my brain can hold before it gets fuzzy from trying to understand it all. Let's not forget my experience and that visualizing something that I don't have experience in is hard at the very least.

---

Official documentation:
- Process documentation & Governmental and Municipality policy:
This are documents for helping and giving information to the residents about their process and who the stakeholders are to get a better understanding of the information. It's policy that we always try to find a professional to give them the right and up-to-date information about what they need to know and what they need to do.

The stakeholders on their turn, often give us back documents or information as a handout to the residents so that we can directly hand people this information. The author of this information needs to be the correct stakeholder and needs to be properly referenced. I'd really like a place to put these handouts and being able to send them to group (ShelterID) or a person (EmployeeID or ResidentID).

- Company policy
I don't think I have to elaborate too much about company policy, but it'll hold all the information regarding company policy. Everything from being sick, to the information about the items you borrow from the company.

---

Here's a virtual pineapple for making the end of this:

 

[MarlonVisser0408]

Above here is more informational; there's not really a question yet in there.

I'm now looking at the logging in screen and the user part of all of this. If anything, maybe someone can enlighten me on how I should look at the permissions being done.

I was thinking about having group permissions that automatically come with your function in the company and having a layer over it with user permissions - have more control on what I want people to be able to see and do. This is purely for the permissions within access and has less to do with security in general.

I included this file as a zip

 

[The_Doc_Man]

I was thinking about having group permissions that automatically come with your function in the company and having a layer over it with user permissions - have more control on what I want people to be able to see and do. This is purely for the permissions within access and has less to do with security in general.

You gave us a bunch to "chew" on and you can probably expect comments to take a while in coming. I saw the above and want to comment on the specific implications. "Group" is unfortunately one of those words that runs into ambiguity in the Windows environment. The commonplace use of the word "group" - meaning some number of people who will use the application in a similar way - can be implemented by determining a User ID in some way and having a user table that lists the groups (or perhaps you mean roles) that each user would play.

The complication is that Windows has groups, too, and they actually have the same meaning - but very different granularity - as the "role" concept that we often see in Access apps. The difficult part is that there is no built-in Access function to test Windows Group Identifiers. You must use one of the Win32 API calls and the one I looked up is ugly. I have used a single Windows Group Identifier as a way to gain/grant permission to open an Access app, but the user role within Access is best determined totally within Access. You would use the user's Domain ID to identify the user and then look up the user's role in a table. There are several relatively easy ways to more reliably determine a user ID if you are in a domain-based environment, and I might suggest some articles by our member isladogs to be an excellent - though not the only - source on that subject. Our SEARCH facilities allow you to put in a topic AND a username for your search, so that should help narrow down some articles.

I'm responding to a narrow subsection of your post simply because it will take a while to digest the whole thing and this is something I could offer quickly. If you really mean from that quote that you want to discuss a user's role in your company as a guide to how they would use the app, the keyword to look up in this forum is "role-based" (with or without the hyphen).

 

[gemma-the-husky]

@MarlonVisser0408

The trouble with spreadsheets is that they don't offer you the strong data-typing at the column level, that you get with a database field.
Their really is no comparison. It's pretty bad that spreadsheets get used for all sorts of things where a database would make much more sense, especially in commercial and even government applications. The problem is that a database requires a much deeper understanding than a spreadsheet, and a casual user just can't achieve credible results.

For instance though, a database is always multi-user, unlike a spreadsheet.

 

[gemma-the-husky]

There's two levels of security, if you will.

The bit that's easy is managing access to a form.

Design a set of user groups, and and users to those user groups. Then limit a form to a membership of a particular user group.
That's easy - as all you have is a function in the open event of a form to check whether the user has access to a form.

Much more complicated is limiting different users ability to do certain task within a form, (eg delete records). as every form will need manual coding to test the function and the user.

 

[gemma-the-husky]

Take a look at my simple security. That's the point of the add/change/delete/view options. Each relevant event calls security as the first line of code in one of the four relevant events and either allows the event to proceed or cancels it.

Yes, but doesn't that mean you have to modify inside the form to call the appropriate function and determine what privileges are needed to execute the event? It's easy if the atomic event is "the form". It's much harder if each form contains multiple decision points. Don't you also need to explain to users how to manipulate the settings to authorise the users.

 

[MarlonVisser0408]

You gave us a bunch to "chew" on and you can probably expect comments to take a while in coming. I saw the above and want to comment on the specific implications. "Group" is unfortunately one of those words that runs into ambiguity in the Windows environment. The commonplace use of the word "group" - meaning some number of people who will use the application in a similar way - can be implemented by determining a User ID in some way and having a user table that lists the groups (or perhaps you mean roles) that each user would play.

The idea is that AccessUserGroup will hold the data from both the group and the AccessUserID. The form AccessUserOption will hold the options inside of it. In my head, they're not often touched. The Group will hold all the things you need to do your job and therefor you don't need to touch the AccessUserOption. The only reason that there's a second layer of permissions is so granting (temporary) access to a part of the application will be a lot easier and has a lot more ways of finetuning, all the while that you don't have to touch a group role or add one.

The complication is that Windows has groups, too, and they actually have the same meaning - but very different granularity - as the "role" concept that we often see in Access apps. The difficult part is that there is no built-in Access function to test Windows Group Identifiers. You must use one of the Win32 API calls and the one I looked up is ugly. I have used a single Windows Group Identifier as a way to gain/grant permission to open an Access app, but the user role within Access is best determined totally within Access. You would use the user's Domain ID to identify the user and then look up the user's role in a table. There are several relatively easy ways to more reliably determine a user ID if you are in a domain-based environment, and I might suggest some articles by our member isladogs to be an excellent - though not the only - source on that subject. Our SEARCH facilities allow you to put in a topic AND a username for your search, so that should help narrow down some articles.

Thats a very good point to make. I'll need to change the names to represent them being different kind of data than the Windows/Microsoft native data carrying the same name.

I've talked at length about some security options with a friend of mine. He's really into helping with small parts and coding at the background and he already looked into my situation for giving me some security outside of Access. There's multiple machines that I'm using throughout the week and some of them don't have the domain setup correctly. He's looking into making a custom set of code and help me get through a proper way of securing things - it's the reason I'm not too worried about that part.
One of the reasons is that we're going to put that part through Windows and my Microsoft environment for liability reasons. *If I understand it all correctly. It took him a flat 3 seconds to start talking about things that went straight over my head

I'm responding to a narrow subsection of your post simply because it will take a while to digest the whole thing and this is something I could offer quickly. If you really mean from that quote that you want to discuss a user's role in your company as a guide to how they would use the app, the keyword to look up in this forum is "role-based" (with or without the hyphen).

Yeah, that's the perfect thing to do here. At least now we got a better idea of some of the difficulties, the scale and some of the reasoning. I hope it wasn't too much of a tough read

 

[MarlonVisser0408]

@MarlonVisser0408

The trouble with spreadsheets is that they don't offer you the strong data-typing at the column level, that you get with a database field.
Their really is no comparison. It's pretty bad that spreadsheets get used for all sorts of things where a database would make much more sense, especially in commercial and even government applications. The problem is that a database requires a much deeper understanding than a spreadsheet, and a casual user just can't achieve credible results.

For instance though, a database is always multi-user, unlike a spreadsheet.

Yes, this I found out. Part of what made me wonder is the ignorance about if it would be able somehow to have both the applications communicate in a better way. Now that I found out that I should not look at them as compatible; things got really easy - no can do.

The idea came from the fact that IMEX=0 worked the way it did. The data that I originally tested the idea on was a passive excel dataset containing area information (provinces, municipalities, cities, neighborhoods). Considering that there was not really any other data then ID's and short texts combined with it being a 'passive' dataset, everything worked beautifully.

This created the illusion that I could implement this to at least the point of me being more knowledgeable about things. You must understand that I'm currently going through the face that I'm redoing a lot of the things I previously did - simply for knowing better. The idea of using excel was more of a way to keep it modular and reduce the amount of stuff that I need to redo. Everything that I connect more data - it updated the spreadsheets and it created a 'database' in its simplest forms with correct data.

As said, I know better now. It's always been about trying to get this whole down to smaller (read: more understandable) parts and less about the database itself.

Much more complicated is limiting different users ability to do certain task within a form, (eg delete records). as every form will need manual coding to test the function and the user.

That's interesting and makes me want look into it, haha. I thought that it was as simple as checking if statements are true? Ignorant is bliss

 

[MarlonVisser0408]

Take a look at my simple security. That's the point of the add/change/delete/view options. Each relevant event calls security as the first line of code in one of the four relevant events and either allows the event to proceed or cancels it.

I'm pulling it apart as we speak! Thank you a lot for this; it's perfect

 

[MarlonVisser0408]

There are only four decision points in my sample - BeforeUpudate, BeforeInsert, Current, BeforeDeleteConfirm. If you want to control functionality within a form so that user A can update fields a,b,c and user B can update b,f,d - that is WAY more complicated and not at all what I suggested. That kind of control requires additional tables and a call to security at EACH point of decision. I don't recommend it. It is better to make separate forms. But, once you have multiple forms to update the same data, you have to call common validation code from each form. Duplicating it will be a maintenance nightmare.

Thank you again for the assistance! It gave me the push I needed to make the solution to my liking. It's good for me to have some ideas reinforced; I'm always scared that my inexperience will cause me to overlook possible solutions. Your post with the form did exactly that!

Of course thanks to everyone else too that helped me to get more confidence and direction into solving this problem nicely.

 

[MarlonVisser0408]

Logbook/Notes System

Introduction​

I’ve been preparing for this part while avoiding it until now: the logbook/notes system.

Concept​

The idea is to integrate multiple logbook entries across various pages and records throughout the application. For example:

• In the Contact Relation Manager (CRM), we manage all contacts, including potential sales leads, residents in refugee shelters, and stakeholders of various locations. This list is filtered based on assigned labels and user/group permissions, which we’ve discussed previously.
• For instance, if I am assigned the role of a sales broker, I should only see leads categorized under the CRM’s “Leads” label, while being restricted from personal logs or unrelated data.

Current Approach​

My plan is to create a form for every record and page that's going to have a logbook section to it. While this will be time-consuming, I anticipate that structuring it properly from the outset will be less of a headache in the long run. (I can make it, connect it and then use the 'hide' function to never look at it again). Each logbook will have a standardized format, making query duplication simple—just a matter of copying and pasting with normalized names.

This setup ensures that the logbook remains functional, even if the application is incomplete. It also allows me to insert historical data early on to validate system behavior before moving on to other sections.

Implementation​

This structure will result in 10–15 logbooks connected to different pages, which will then merge into a unified query. Normalized data entry will minimize complexity during merging.

Potential Concern​

I’m concerned about the performance impact of handling extensive long-text fields in a large query. However, I believe that filtering queries at a binary level before generating content could mitigate this issue. Does this approach make sense?

User Permissions and Filtering​

The merged logbook data will be filtered based on user and group permissions, as discussed earlier. This ensures that sensitive data is not exposed in an unfiltered query. By pre-filtering queries, I can seamlessly integrate them into pages and records while providing a reply section in the footer. This allows users to add relevant information without navigating away from the record, ensuring data consistency and efficiency.

Automated Entry Registration​

I would love to automate data tracking for log entries. Ideally, each record should include:

• CreatedBy
• CreatedOn
• ModifiedBy
• ModifiedOn
• ChangedData

This would greatly aid in tracking data integrity, rolling back errors, and reducing the need for manual log entries. For instance, if a user schedules a dentist appointment for a resident or orders a taxi, the system should automatically generate a log entry without requiring manual input.

Learning Path and Challenges​

I’ve struggled to find solid learning resources on automating this type of data logging in Access. While searching YouTube, I encountered more unanswered questions then solutions and it drove me crazy. I'm pretty sure that I'm using the wrong keywords to get to the information that I need.

Example Scenarios​

• Game Development Example: In a turn-based system, pressing a button should create a new table entry. Each subsequent button press should append another entry, generating data based on the previous one.
• Company Inventory Example: A live inventory system should automatically update stock levels when new items arrive or are used. If stock levels drop below a threshold, an automated request should be sent to the order form, ensuring a continuous inventory cycle.

I’d appreciate a pointer towards a place where I can learn about these problems. Does anyone know a good course or an author?

 

[MarlonVisser0408]

A logbook is a logbook and you should never duplicate tables. If you were Amazon, would you create separate product tables for each type of product you sell because they have different attributes? NO, you would not.

This very much makes sense; it was the reason I was already struggling with this idea. Good to have this confirmed. So I'd be way better off making a single logbook and adding some automated values to the way the entry was made (if it's made on a residential record, we already have the data needed to do this). I believe that what you're saying is the thing that I initially thought would be the best way to implement it.

Queries filter your data depending on how you want it reported and who is making the request. If certain users are restricted to certain entity types, then you need to set up security to handle this.

Yes, the intention is to precode all the security into it to the point that you can use the UserRecord and UserGroupRecord pages to change someones access based on booleans - what we discussed earlier.

This doesn't happen automagically. You need to write code to make it happen. Sometimes you can use Triggers but code in forms might be more flexible.

I shouldve been more carefull with my words. I want to precode it all to the point that the front-end prints the data automatically, based on how I got it coded on the backend.

I wouldn't use Access to create a game. If each record is linked to the previous entry, you need to add a FK to the previous entry as you add the current entry. By definition relational tables are unordered sets of data and no row has any relation to any other row. To overcome this requires user coding.

It was something I was working on at the start. A project to play with and to learn access by running into various problems and gaining some experience this way. I'm fully aware that Access is the wrong platform to be distributing a game from, but as far as I know; you could do it for the sakes of just learning

Inventory levels are NOT stored. They are calculated when you need them. When you fill an order, you calculate the remaining quantity using a query and if necessary generate a replenishment order.

Could it be as simple as having a single table that's working with positive and negative values?

Do not restrict your searches for Access solutions. ANY solution created with a relational database will show a reasonable schema based on that application's business rules. The thing to be careful of is restrictive business rules. There will NEVER be more than 3 items on any order. The user may tell you this but bells should be clanging very loudly in your head because you know that no order has ever had more than three different items because the company only sold 3 products. Duh! Once they add a fourth, then that business rule vaporizes. So make sure the rules you are implementing are not red herrings.

No, I'm very aware of this. One of the reasons that I'd very much like to save this kind of information is so I can add simple checks to notify me of interesting input. For example, it'd be very weird to see an entry being made at 02:00AM. I'd very much like to know if someone makes a log at 02:00AM and the details surrounding this event.

I think it'd be very wise for me and helpful for the user to have this done correctly and nicely. As said, I don't care the investment from my side of the story; I need the user to have a good experience rather then me having a good experience

 

[MarlonVisser0408]

To be auditable, inventory needs to be handled with a transaction table. Every item movement in/out/adjustment is a transaction. I use natural signs. A positive number increments inventory and a negative number decrements it. Sum the transactions to find the current balance. That means a sale with a positive sign is actually a return. But usually you would have discrete transaction types so you don't have to work these out by analyzing the sign of the transaction.

If you have a huge set of data with lots of movement, a few years down the road, you might want to archive details and replace them with monthly summaries once you're sure the individual actions are no longer relevant.

Thats a good point to set my head towards. As soon as I am able to understand how the mechanics work, I feel more comfortable doing work that I know how to do, while learning what I need to learn here - I hope that makes sense. Thank you for this, this is exactly what I needed.

The idea of the automated logs and most of the data, I want to eventually make it so that every X amount of months, we convert what we have to excel and basically get rid of it. There's not enough moments that we look back to history beyond the threshold that I need to have the data ready on hand. I rather have the database to run smoother, this collective time saving will outweigh us doing it manually at times.

95% of the database will exist out of very wide data. It'll be a lot of tables, containing sometimes 20 entries, sometimes 300-400 - but never big amounts of data. On the taller data, I'll make sure to cap the amount of items it'll hold.