Programacion general desde cero

De acuerdo Kryptonyte, y yo diría que la gran mayoría de las aplicaciones, si las vemos por cantidad, SON simples. Y se pueden implementar muy bien sin recurrir a plataformas complejas para el manejo de datos.

Hace muchos años el almacenamiento era carísimo, y había que hacer algoritmos muy complejos para reducir el espacio ocupado. En este momento, si no me equivoco, en una PC el disco cuesta en nuestro país aprox. un dólar por GIGAbyte y el acceso es 1000 veces más rápido. Esto produjo un cambio cualitativo muy grande en el manejo de datos. Quedaron en el absurdo todos los esfuerzos por reducir el espacio en disco, y se abrieron mil posibilidades para los programas simples, que hicieran uso de disco A MANSALVA, con tal de conservar la simpleza.

Lo mismo pasó con la memoria RAM. Imaginate cómo se siente un programador experto (pa no decir viejo) recordando cómo había que retorcer y fragmentar programas para que entraran en 64 kbytes, y ahora tiene una RAM por lo menos 30,000 veces mayor !

Las bases de datos que antes eran exclusividad de los mainframes, llegaron a la PC y se instalaron cómodamente. Bueno, con cierto costo, no olvidemos. Antes vendían 1 sistema a 50,000 dólares, ahora venden 1000 sistemas a 1000 dólares, multiplicaron la ganancia por 20, o me quedo corto?

Entonces lo que quiero remarcar es que ese mismo beneficio que aprovechan Oracle, Microsoft y demás, lo podemos aprovechar nosotros, y nuestros programas trabajar con una amplitud y una comodidad jamás soñada, logrando aplicaciones 500 veces más veloces, y si la velocidad no fuera importante en algunos casos, sí es importante la independencia de sistemas ajenos, y sus costos. Y sus defectos, que los hay ! Prefiero mil veces lidiar con un defecto mío y no de un sistema database.
Aguante ChotoBase !

Considero que lo más importante para programar eficientemente es la llamada función big-O de un algoritmo, que determina su comportamiento asintótico. Los casos más comunes son O(1), O(log n), O(n), O(n*log n), O(n^2), O(n^3), O(n!), O(2^n).
Un algoritmo aplicado a n elementos tarda un tiempo proporcional a uno de esos O().
Hay muchos casos en que un algoritmo simple tiene por ejemplo un tiempo O(n*n), y uno más sofisticado O(n*log n). El algoritmo simple puede ser superior para 10 elementos, pero para 10.000 puede ser prohibitivo. Ejemplo: sort por inserción versus ShellSort.
Entonces, lo que hay que buscar es no sólo la solución más simple sino la más eficiente que se pueda aplicar al problema. Por suerte, hay enorme cantidad de literatura técnica al respecto.
Hoy día el problema principal de eficiencia reside en el tiempo de proceso, no en el espacio ocupado. No obstante, en algunos casos ocupar poco espacio puede resultar muy beneficioso. Por ejemplo, hay problemas para los que basta almacenar un solo bit por cada dato. Si en cambio usamos un entero, o un registro de disco, la eficiencia decaerá enormemente.
La eficiencia es un tema que da para mucho.
Saludos.

Excelente observación. Ahora lo que interesa es la eficiencia, y afortunadamente es mucho más fácil de conseguir que , digamos, 20 años atrás.

Un factor del que no hablamos, y que también corresponde al tema "Programación desde cero", es el trabajo en equipo. Es sabido que un proyecto para un solo programador debe ser clarísimo y estar muy bien documentado, porque si no, ese mismo programador no entenderá nada de lo que hizo, pasado un año. Mucho más delicado es el tema cuando son varios programadores en el mismo proyecto o en otros proyectos que usan los mismos datos.

En ese caso mi veloz ChotoBase tiene un inconveniente grave: el diseño de datos es mío, y si no lo documento bien, va a ser más fácil para otros programadores hacerlo de nuevo, que modificarlo o usar sus datos en otra aplicación. Ahí es donde brillan los sistemas SQL, porque las estructuras están a la vista y son modificables (con cuidado) sin afectar programas existentes.

Por ejemplo, yo tengo definido un diseño de registro para una Carta de Porte (documento que acompaña y legaliza la carga de un camión y después sufre muchos procesos), que tiene muchos datos de distintos tipos, que ocupan 1400 bytes. Para mayor eficiencia de disco, lo dimensiono a 2048 bytes dejando esos 648 bytes vacíos. La semana que viene la AFIP pide que se agreguen los Nros. de Patente de Hasta Cuatro Perros que Persiguen al Camión, y fecha de vacunación (del chofer). Bien, tengo lugar y lo agrego, amplío unos campos en la pantalla de Carta de Porte, introduzco unas validaciones, envío el nuevo programa a los usuarios, y chau. Pero si me piden ALGO QUE OCUPE 650 bytes ? Si no encuentro un lugarcito libre, tendré que definir un NUEVO diseño y hacer un programa CONVERSOR que lea el archivo original y pase todo al nuevo archivo, obviamente parando los sistemas y realizando el proceso en 10, 100 ó 500 usuarios.

Esto lo resuelve un sistema DataBase sin necesidad de convertir nada. Puede hacer esto y mucho más, y los datos siguen accesibles para los demás programadores y las demás aplicaciones.

Ahí tenemos entonces otro de los criterios que hay que evaluar ANTES de hacer la primera línea de código. Hay otros programadores en mi proyecto? Hay otras aplicaciones que usen mis datos ? Debo usar yo los datos de otras aplicaciones ? Es aceptable exportar/importar datos en formatos compatibles, o necesito compartir datos en tiempo real?

Nótese que no hablo de otros USUARIOS de la misma aplicación en una red. Eso se resuelve muy bien con un esquema de bloqueo y desbloqueo de archivos compartidos, para evitar que dos usuarios choquen en la modificación de un registro, sin recurrir a Base de Datos.

Por las dudas, toda la entrada/salida a disco en mi sistema, está concentrada en una biblioteca de procedimientos genéricos llamados DBIN(..) DBOUT(..) DBEXTRAER(..) DBNEXT(..) DBPREV(..) DBEMPTY(..) DBEXISTS(..) etc. que diseñé justamente para poder un día reemplazar toda la entrada/salida por llamados a algún sistema Base de Datos standard. Pero así no voy a aprovechar todo el sistema Base de Datos. Simplemente voy a salvar el resto de mi programa de caer en el olvido total. No va a ser más eficiente.

Perdón por la extensión, saludos !