Sto scrivendo un sacco di stored procedure per un database SQL Server che accetta un id o un codice che è un CHAR invece di un INT . La maggior parte di questi non ha cambiato la dimensione in un tempo lungo, ma quando un cliente vuole aumentare le dimensioni che generalmente facciamo. Questo non sarebbe un problema tranne il fatto che qualsiasi stored procedure con un parametro digitato CHAR(4) si interromperà all'improvviso.
Ho tre idee per mantenere le dimensioni delle colonne in un'unica posizione, ma non so se mi piacciono. Per prima cosa è sufficiente utilizzare un tipo molto più grande del necessario, ad esempio VARCHAR(100) . Ci sono conseguenze negative per questo oltre alla mancanza di chiarezza nel codice?
Secondo è che gli script che generano le procedure cercano la dimensione della colonna per definire dinamicamente i loro tipi di variabile. Sarebbe meglio, ma non sono sicuro che sarebbe possibile senza un sacco di SQL dinamico, e avremmo ancora bisogno di rieseguire tutti gli script quando qualcosa è cambiato.
Infine, ogni volta che uno script aggiorna le dimensioni di una colonna, potrebbe anche andare e aggiornare tutte le stored procedure che fanno riferimento ad essa. Mi piace di più, ma in una grande organizzazione con molti programmatori sarebbe facile per qualcuno dimenticare o perdere una procedura.
So che usare INT ids o un ORM dovrebbe evitare del tutto il problema, ma sfortunatamente c'è già un sacco di codice usando le stringhe, e il refactoring del database non è una priorità aziendale.