The correct answer is: it depends on which database engine and on which management tool.
Let's make an example:
We have a report table,
and a report can have a parent (menupoint, like category),
and that parent can itselfs have a parent (e.g. Profit center),
and so on ad infinitum.
The most simple example of a standard recursive relationship, as with any self-referencing entity / hierarchy.
The resulting SQL-Server table is:
IF EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'dbo.FK_T_FMS_Reports_T_FMS_Reports') AND parent_object_id = OBJECT_ID(N'dbo.T_FMS_Reports'))
ALTER TABLE dbo.T_FMS_Reports DROP CONSTRAINT FK_T_FMS_Reports_T_FMS_Reports
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'dbo.T_FMS_Reports') AND type in (N'U'))
DROP TABLE dbo.T_FMS_Reports
CREATE TABLE dbo.T_FMS_Reports
RE_UID uniqueidentifier NOT NULL
,RE_RE_UID uniqueidentifier NULL
,RE_Text nvarchar(255) NULL
,RE_Link nvarchar(400) NULL
,RE_Sort int NOT NULL
,RE_Status int NOT NULL
,PRIMARY KEY CLUSTERED ( RE_UID )
ALTER TABLE dbo.T_FMS_Reports WITH CHECK ADD CONSTRAINT FK_T_FMS_Reports_T_FMS_Reports FOREIGN KEY(RE_RE_UID)
REFERENCES dbo.T_FMS_Reports (RE_UID)
-- ON DELETE CASCADE -- here, MS-SQL has a problem
ALTER TABLE dbo.T_FMS_Reports CHECK CONSTRAINT FK_T_FMS_Reports_T_FMS_Reports
But you get a problem:
When you need to delete a menupoint with all its submenupoints, you CANNOT set delete-cascade, because Microsoft SQL-Server doesn't support recursive cascaded deletes (on the other hand, PostGreSQL does [but only if the graph is not cyclic], while MySQL doesn't like this kind of table structure at all, because it doesn't support recursive CTEs).
So you kinda blow up deletion-integrity/functionality with it, making it mandatory to implement such functionality in your own code, or in a stored procedure (if your RDBMS supports stored-procedures).
This will no doubt blow up any kind of fully-automatic dynamic data import/export, because you can neither simply run a delete statement for all tables according to (non-self referencing) foreign-key relationships, nor can you do a simple select * and create an insert for every row in an arbitrary order.
For example, when you create an INSERT script using SSMS, then SSMS won't get the foreign key, and thus does indeed create insert-statements that will insert entrys with dependencies, before it inserts the dependency's parent, which will fail with an error, because the foreign-key is in place.
However, on proper database management systems (like PostgreSQL), with proper tooling, this shouldn't be a problem. Just undestand that just because you pay a lot for your RDBMS (I'm looking at you, Microsoft; Oracle = ?), and/or its tool-belt, it doesn't mean it is programmed properly. And neither does OpenSource (e.g. MySQL) make you immune to such wonderful minutiae.
The devil is in the details, as the old saying goes.
Now, not that you couldn't work-around such problems, but I really wouldn't recommend it, if your system is gonna be complex (e.g. 200+ tables).
Plus, in a usual commercial setting (as portrayed by Dilbert), you just won't be given that time.
A much better approach, though more difficult, would be a closure table.
That would have the added bonus that it also works on MySQL.
Once you implement the closure-functionality once, you'll have it working in additional places in almost no time at all.