1) Non credo ci sia differenza "tecnica" tra l'utilizzare nomi di tabelle e/o di colonne in inglese o, per esempio, in italiano.
Di certo l'inglese è comunemente utilizzato in quanto "lingua universale"; in un grosso progetto è probabile che lavorino team di più persone, magari di nazionalità diverse, e che il lavoro di sviluppo e mentenimento duri per anni. L'utilizzo di un linguaggio "comune" è certamente un vantaggio.
Tieni presente peraltro che in molti casi il nome delle tabelle o delle colonne non è "parlante" quindi non ha necessariamente un nome o una sigla che, in una qualche lingua, significhino qualcosa (tanto per fare un esempio i nomi di alcune tabelle di SAP sono DD02T, DD02L ed i nomi di colonne sono MANDT, WERKS, MMSTD, etc)
Peraltro, visto che proprio l'inglese è anche la lingua dei vari linguaggi/dialetti SQL (select, insert, drop, index, table etc) l'uso di una lingua NON inglese eviterebbe il rischio di utilizzare parole "chiave" come nome di tabella o di colonna (a cui si ovvia facilmente usando la sintassi [parola], ma tant'è...)

2) Anche io lascerei il campo ID autoincrementante come chiave univoca; è più semplice da gestire e da utilizzare (chiavi esterne, query, etc). Introdurre un campo stringa dataora + persona mi sembra un po' forzato e rischi di non poter utilizzare questo campo per alcun altro scopo. Meglio, come suggerisce MacApp, utilizzare eventualmente due campi separati (dataora e id persona) indicizzati

3) Eviterei proprio l'introduzione e l'utilizzo di "doppioni" (tabelle identiche con dati replicati); non solo aumenti inutilmente le dimensioni del database ma rischi di ritrovarti con maggiori problemi nella gestione successiva di query o reportistica (se cerco informazioni storiche relative ad un socio, a seconda del fatto che sia ancora presente o che sia stato "cancellato", dovrei andare a fare ricerche in una tabella oppure in un'altra...)
Fai attenzione che la "cancellazione" di qualcosa (ad esempio di un socio, ma più in generale di qualunque cosa) non necessariamente prevede l'eliminazione dei record e delle loro informazioni (con la relativa necessità di gestire copie, archiviazioni, record orfani) ma molto più opportunamente, come suggerisce MacApp, puoi gestire il tutto con un campo aggiuntivo "stato" che valorizzerai in maniera adeguata (es. 0 = nuovo socio non abilitato, 1 = socio presente, 2 = socio sospeso, 3 = socio cancellato, etc...ho messo descrizioni a caso... solo come esempio...)
L'ID autoincrementante assegnato ad ogni socio al momento del suo inserimento resterà comunque SEMPRE presente nel database (anche dopo l'eventuale "cancellazione" del socio) e ti servirà come chiave per collegare tutte le informazioni a lui relative