You will get errors if you restore a row that contains a value in nQuestionId2 that references a value in nQuestionId1 that has not been created yet.
There are a few ways to resolve this issue:
- You could ensure that you create the data in the correct order.
- You could disable the foreign keys before importing the data, then re-enable them after.
- If disable/re-enable is not an option, you could drop/recreate them.
- Alternatively you could split out the data so that the nQuestionId1 is in a separate table - this will allow you to restore all the nQuestionId1 values first.
I guess but the question really is about what you are trying to achieve.
I have seen designs like this that have a ID column and then a PARENT column that references the ID. In order to get the root parent you have to recurse through all of the parents of the object you are looking at. This means that even though a design like this may make sense logically, querying it could become quite difficult.
Database design is not just about mapping business rules and objects to tables and constraints, but also thinking about what is maintainable, how will the design hold up against large amounts of data, and being pragmatic about your approach.
I hope this helps you.