The family 'family_id' is a foreign key to id in the people table.
You have this relationship backwards. The people.family_id should be a foreign key to the family.family_id table.
CREATE TABLE family ( famliy_id INT PRIMARY KEY ); CREATE TABLE people ( id INT PRIMARY KEY, name TEXT, age TINYINT UNSIGNED, gender CHAR(1), family_id INT NOT NULL, FOREIGN KEY (family_id) REFERENCES family(family_id) ON DELETE CASCADE );
The answer to your question is yes, you need to insert to family separately, and before you can insert to people. In SQL, an INSERT statement can insert to only one table at a time.
There could be a way to write a trigger before insert for the people table, which uses INSERT IGNORE to insert the family_id to family just in case it isn't there already (and the IGNORE part means it's not an error if the value is already in that table). But I wouldn't do this, it's needless overhead to run a trigger for this case.
family has only one table because when i delete a family -> all the people in the family will also be deleted
This doesn't require a second family table at all. It's true that the foreign key allows you to DELETE FROM family WHERE family_id = 123, and the cascading delete affects the people table.
But if you didn't have the family table or the foreign key referencing it, you could still delete from the people table, and in fact it would actually be more efficient to simply DELETE FROM people WHERE family_id = 123.
If there's something more complex about your model that you aren't telling us, like multiple child tables referencing family, then it might be worthwhile to have the cascading foreign key to simplify deletions.
DELETE FROM people where id={family_id}.DELETE FROM people where family_id={family_id}