Cita: ps: creo que este tipo de validacion no aplicaria al crear articulos, usuarios o empleados?
No. El ingreso de empleados, usuarios, artículos y otras cosas de ese tipo son el tipo de altas que se hacen de forma esporádica, y donde no es relevante la secuencialidad de lo identificadores autoincrementales. En realidad el análisis de las altas para antigüedad o precedencia se hace en base a la fecha de alta, que siempre se guarda como DATETIME o TIMESTAMP para eso. Por otro lado recuerda que ese tipo de datos son de uso administrativo interno a la emrpesa, en cambio la facturación no.
Además, las interfases desde donde se hacen esas altas son de uso muy restringido, es decir, no todos los usuarios deben poder dar de alta un artículo, ni a otro usuario. Por eso esas funcionalidades solo se usan de forma puntual, e incluso de se pueden hacer de modo diferido.
En cambio los proceso de facturación siempre tienen impacto inmediato, por lo que su secuencialidad es fundamental.
Ahora bien, una nota. En los casos donde el sistema no tenga concurrencia, o bien donde haya un manejo de transacciones muy bueno, de todos modos es posible usar métodos que te permitan administra los autoincrementales, si usas tablas InnoDB.
Requiere leer el manual de referencia, que está en inglés:
http://dev.mysql.com/doc/refman/5.7/...vel-locks.html http://dev.mysql.com/doc/refman/5.7/...y-locking.html
Lo que sí NUNCA debes hacer es usar sentencias DDL como ALTER TABLE para realizar modificaciones como las que hacías. Son riesgosas, innecesarias, y además cualquier sentencia DDL que se ejecute generará un COMMIT implícito para todas las transacciones en curso, lo que podría dejar asentadas operaciones que no deben confirmarse, y hacer caer en error todas las transacciones que se estén ejecutando, si la llamada a su inicio y finalziación la manejas en la aplicación.