There is an Assets Starter solution that comes with FileMaker 13. Even if this solution does not meed the precise needs you have for a database, you may find that there are methods and ideas used in it that you can adapt to your own solution.
There is a free tutorial on FileMaker 13 produced by FileMaker Inc.: https://itunes.apple.com/us/book/filemaker-training-series/id787527886?mt=11
When it comes to tracking very dissimilar items there are two parts to the process:
First, sit down with a piece of paper and list every type of item you might possibly need to track at this time. Don't stress out too much about forgetting an item or two or the fact that the items you need to track will change as your business changes, this is just to get a starting point and you can add in more details at a later date--even after you have your database up and working.
Then, for each item that you listed, list every detail about that item that you might want/need to record in your database.
Then compare the lists of details--which will become fields in your database tables and organize them into two groups: One group is all the details that are common to all items that you will track. That might not be more than an ID number of some sort and a text description or there may be additional details common to all. The second group will consist of all the other details that are not common to all assets such as your electronic equipment details that won't apply to uniforms or safety equipment.
Then you come to step 2. There are two basic design approaches you can take for how you handle these two groups of asset details.
Option 1 is to set up a single table with a field for every possible detail--whether that be a detail from group 1 or group 2. If you have a record for a uniform in this table, the fields specific to electronics would be left empty and vice versa.
Option 2 is to set up a table with only the fields common to all types of assets. You then set up a series of related tables for groups of the asset specific details. You might have a Uniforms table with fields for size and type of uniform and an electronics table with fields specific to electronic equipment. A record for a uniform would have a matching record in the uniforms table, but no related record in the electronics table.
With either approach, you have a single table where you have one record for each asset. Make sure that you define an auto-entered serial number or text field with Get (UUID) to uniquely identify each record and to link it to any other related records in your system. Don't use a serial number copied from the physical item in place of this field as this set's up issues such as incorrectly entering the value and later having to correct it that can really complicate your life if you used that field in place of the auto-entered identifier as your primary key.
With either approach, you can set up different layouts for different types of assets customized to the needs of that type of asset (or group of similar assets) And with either approach a related table can track the person to whom the asset is currently issued and another table might track the physical location of assets that have a specific location that can be specified.
The main difference between the two methods is that using multiple tables for the details is more complex to set up in Manage | Database | relationships, but breaks up what could be a very large list of fields into smaller, more easily managed groups of fields. It can also produce a smaller database file, but given the massive capacity of modern hard drives, that difference in file size may not be significant when it comes to actually using the database.