It depends whether it is my database for my own work or for a customer.

For my database, my biggest problem is I start with a more complex design than I need to.

For customer databases, it is just getting the customer to vocalize what his problem is rather than telling me how to fix it.

Planning the database.

-Raymond

My biggest struggle is that when I get it where I think it is just right, you release a cool new lesson (like filtering the combo box, or the recurring transactions form) then I realize it's not as perfect as I thought, and I tweak them some more. LOL

Mine is relationships and joins

For me, it's the reports. It used to be the relationships, but the seminar helped a lot to clarify that. Databases are a hit or miss. I start with something larger than life and always end up cutting it down to something easier to manipulate; the result makes me happy.

Getting all of the detail sorted out.  It seems like it takes a long time to get the fonts, alignment, colors, properties, etc. set the way that I want them.

Stopping building at a decent hour.
I've seen me still working in the wee hours of the morning.

Designing the database to model the task at hand used to be the most difficult.  Until I discovered yEd Graph Editor.  This free utility lets you play around with table & relationship designs so you can visualize the db schema - before you start building tables, etc.  I use it on all of my projects anymore and it's very handy!  https://www.yworks.com/products/yed

There are tons of challenges facing new students, old pros, new databases, and decade-old databases alike. Like Kennedy said, we do things because they are hard.  A simple thing like naming your tables, fields, queries, VBA variables, procedures, etc., can be hard.  Commenting your code can be challenging.  A big shortcoming of Access is that you can't put comments inside queries (in SQL Server, you can).  Some people use "naming conventions" in VBA code, which is a hurdle in itself.  But the most challenging thing of all is creating a global error-handling system, which is a tough thing not just in Access, but practically every platform.  You don't want your users see Access run-time errors.  You need to trap every possible error and show user-friendly error messages.  This involves every procedure in your code.

I'm working through the process of linking my tables in a way that supports the queries and reporting I need. I've been following the method you demonstrated in one of your videos where you first map out the relationships in Excel to get the structure clear. That part I can follow, but where I'm struggling is the implementation in Access:

How to define the relationships so the joins return the correct results.
How to structure queries so I can bring the related data together.
How to extract the specific fields I need without ending up with duplicate or missing records.

I understand the theory from the Excel layout, but I'm hitting a wall when it comes to applying it inside Access to actually pull the information together.

the technical stuff, the coding and logic is what i struggle with most.
The planning is easy, looks/design is a bit of a challenge but I get there eventually.

But the real challenge is getting the functionality working.
Getting what's in my head out my head and into a working solution.
Between YouTube and here the brain has an all you can eat buffet on knowledge and it's slowly getting fatter as it slowly, very slowly, digests it all.

Access will show you a Data Model only AFTER you have created the tables. As a Data Architect for many (many!!) years before my recent retirement I find it more than useful to create the Data Model before beginning the database in Access. Even if it's only on a sheet of paper (of course a data modelling tool is best) list all your tables with at least the Primary and Foreign keys and then add the relationships. Creating the database tables is now made much easier by following your data model design and then adding all the other necessary attributes. If you now use Database Tools: Relationships, add all tables and replicate the relationships you will effectively have the data model for reference in future enhancements.