>I need to store addesses for different entities. I will create an address table. Anything wrong with creaing a 'ParentID' column and then populating it with the PK of the entity the address belongs to? I know some would say that you shoulds create a CustomerAddresses table and an EmployeeAddresses table, and so on. What do you think?

A customer table typically is linked to a contacts table as well. For your employees that record may contain the emergency contact person if you want to use the contacts table for two purposes as well.

If you share the address table, you could identify the type of address table record with a code (E for employee C for customer). If the address table also includes the header information, you could link it to the contacts table (if the address table actually contains more information than just the address) for both customers and employees. Not sure by your description if the address table only includes addresses and nothing more.

Or you can have an employee table and a customer table and just link them to the address table and to the contacts table by a key. (My recommendation but add a code in the address table to denote the type of record it came from if you will be doing a LOT of reports based ONLY on geographic location later - and I mean a LOT where you don't want to look at the header record first to determine which records to pull in the address or contacts table)

I've seen a lot of backends and typically it is employee table and a separate customer table and they both either include the address information or they both point to a separate (often shared) address table.

How will you use this data later in reports? Will you be mostly reporting using only the header information (names and relationships) and then only include addresses in detail reports? Will you ever be producing graphs of any type? maybe customer type or address location by state or geographic location or anything? You will need to be able to separate out the customers from the employees for specific reporting requirements. Just make sure you don't normalize to the point where you cannot produce any reports you may need in the future (without really taxing the backend to produce that report) same thing with your contacts table and any other tables you have. Think of the reporting you will do later...
What about reports on the area codes of all of your customer's? Do you need a 1-800 number down the road and need to justify it? How many customers have cell phone contacts? Will you be sending out notifications of any type via email or text messages in the future? Do you need to break down employees by county ever? Will you be breaking customers down by state or county or city? Etc... Consider multiple contact records per employee and customer - so multiple address records as well. What type of contact are they? Are they a primary contact (customers), emergency contact (employees), or additional contacts for other purposes? Do you need to identify the type of contact down the road for any special purpose? Etc. Don't forget pager numbers, etc. Do any of your customers have their own website you need to put in your records?