I would add as an initial disclaimer that when you say DB and this question has tags indicating several platforms, that we are talking about a traditional relation database - i.e. a well-defined system which manages data in tables, columns and rows, according to Codd et al. This is a well-defined paradigm with well-understood boundaries.
If you are talking about a bunch of spreadsheets or files in a folder (many people do call this a database), or any similar non-relational database (perhaps under the umbrella term NoSQL), none of this has to apply.
I would always begin a project that uses an RDBMS as an RDBMS by using foreign key constraints. You can always relax constraints later. I would also normalize first, and denormalize as necessary.
It's far easier to relax a constraint later or refactor tables if you are starting from something where there are guarantees.
Similarly, I'm going to try as best as I can to identify the proper data types, ranges and nullability of columns at the beginning. I'm going to default columns to NOT NULL until there is evidence that the model requires NULL. I'm going to have a primary key on all tables, and where there isn't an obvious choice (either natural or surrogate, depending on the design philosophy), I'm going to add a surrogate, so that it will be at least possible to uniquely identify a row among otherwise identical rows if I have to do a DELETE operation.
These things can all be relaxed later, but adding constraints later is going to require you to figure out what was wrong in the data before you can apply a constraint.
These are just a few of the basic rules of thumb which keep your database on track as you start development. Refactoring from one structured design to another structured design (of whatever quality or philosophy) is a lot easier than refactoring from unstructured.
In my experience, an evolving database design will outlive many front-end applications over its lifetime (sometimes several simultaneously), so it makes sense for it to provide a boundary of services which are always consistent and uniform. For this reason, it is unwise to expose tables directly or to treat the database as simple persistence for any things which gets thrown at it. If you expect the database to just hold anything with any rules which may vary over time, the value of the database itself is lowered, and it will have issues with data quality, uncertainty about semantics and all associated issues surrounding that.