MySQL Forums
Forum List  »  Spanish

Re: importar tablas mysql - mal diseño
Posted by: Gonzalo Garcia Correas
Date: June 29, 2011 07:37AM

Es un poco difícil responderle con cortesía a un tipo que se presenta como "fernando la verdad no les importa". Francamente resulta una grosería, pero si ese es el tono que quieres usar, allá tu.

Antes que nada, voy a aclarar unos detalles:
- Yo empecé a trabaja con con el dBASE III+ y luego con Fox Base+, por lo que en realidad parece que comencé antes que tu. La diferencia es que yo no me bajé de la ola tecnológica. Evolucioné con ella.
- Incluso comencé a programar con GW-Basic, lo que me pone casi en la categoría prehistórica, para los que actualmente trabajan conmigo, pero claro, ahora programo para aplicaciones .Net, PHP, JSP, y un largo etcétera, incluyendo la interacción con las BBDD.
- Como si esto fuese poco, comencé diseñando bases de datos casi con COBOL, por lo que mis conocimientos datan de antes del SQL. Pero hoy manejo 4 DBMS diferentes.

Creo que con estos detalles debo tener las cosas suficientemente claras. ¿No crees?

A mi entender, uno de tus problemas para manejarte con las bases de datos actuales es que tu no te dedicaste en este tiempo a la informática, sino a la ofimática. Por ello cualquier cosa que vaya más allá de los recursos de oficina (Access, Excel, Word, Project, etc.) te resulta innecesariamente "complicado". Ese es un problema de los que se han alejado de la evolución tecnológica sobreespecializándose en áreas de trabajo.
No hay problema. Mis PM tampoco entienden nada de esto.
Pero toda esa lejanía no te autoriza a tratar de imbéciles, o cosa semejante a quienes se enfrentaron con desafíos evidentemente fuera de lo que has tenido. La aparición de los DBMS no surge por "ocurrencias" de algún afiebrado, sino por las mismas necesidades del uso de la tecnología de información. Todo lo que aprendiste y usaste y quieres seguir usando carece de capacidad para soportar los requerimientos que los usuarios les ponen. Por eso se crean. No por estupidez, sino porque te agrandaron la cancha y un jugador de Futbol5 (por usar una imagen), no se banca correr 90 minutos en una profesional.
Yendo a tu ejemplo: Una aplicación portable en un CD (o en un floppy, en mis inicios) no alcanza para manejar la información que actualmente se almacena, y menos aún para responder a la flexibilidad que los usuarios quieren para los datos que buscan. Eso podía suceder cuando lo que el usuario quería eran listados de datos, o reportes básicos de entradas/salidas. Pero en cuanto alguien preguntó en qué sucursal se vendían mas de ciertos artículos, y cómo se desglosaba esa venta por subcategoría, por cliente, por domicilio de los clientes, por edad, y por tipos de intereses de los clientes... En ese momento el dBASE pasó a ser basura.
¿Crees que exagero? ¿Cómo te crees que se preparan los target de las campañas publicitarias? ¡BI, por supuesto!
Pero FoxPro, dBase III y demás no tienen capacidad para hacer eso, y crear un programa para un cliente capaz de hacerlo implicaría precisamente construir... un sistema de gestión de bases de datos, y también eventualmente un lenguaje propio, para resolver cosas que eran repetitivas. En otras palabras: los DBMS y el SQL.
El problema base es que tales necesidades llevan a sistemas más complejos, donde la información no puede almacenarse ya en un simple archivo. De hecho ni siquiera en una tabla, porque cualquier uso de un archivo por tabla hace que tarde o temprano llegues al límite que el sistema operativo puede manejar.
Ese es el núcleo de los problemas: Lo que tu quieres usar por añoranza, son aquellas cosas que han quedado demasiado limitadas para lo que se necesita. Un sistema de archivos no puede usarse para soportar la base de datos de Ford Motors, o de la sucursal del supermercado de la esquina de tu casa, sin pagar enormes costos en tiempo y dinero por la cantidad de cuellos de botella que te ponen esos medios.

Veamos algunas de tus quejas:
- ¿Por qué no hay un "abrir" y un "grabar como..."? Porque no son tablas, son estructuras más complejas y el sistema de archivos no puede representarlas ni soportarlas.
Una parte de la base puede ser un archivo, pero una base de datos es (hoy) algo más complejo que eso. La base de datos como conjunto de tablas dejó de existir en el momento en que se empezó a trabajar el modelo relacional (que no es solamente que A se relaciona con B a través de un valor).

- ¿Por qué necesitas un servidor funcionando para un DBMS? Porque no es solamente un sistema de tablas, sino que además contiene una enorme cantidad de algoritmos aplicables a consultas, selecciones, búsquedas, etc., que de no tenerlas deberías crearlas tu. Además, contienen lógica estadística que permite crear diferentes alternativas de acuerdo a las consultas, y responder can la más eficiente dependiendo de la forma en que se respondieron las anteriores. A esto agregale un uso directo de memoria, administración de búferes de datos, de consultas, de indices, etc. Todo esto es mucho más simple y eficiente teniendolo en una entidad separada y encapsulada, a la cual lo único que haces es pedir y que simplemente te responde con lo que solicitaste, por complejo que sea.
Nada de esto lo tenía dBASE III y apenas se esbozaba en el FoxPro.

- ¿Por qué necesitas que MySQL "digiera" los datos primero? Porque los datos no están en los archivos de las tablas. Están en otra parte, y se hace así entre otras cosas para evitar el límite de tamaño de tablas que pueda imporner el sistema operativo. En ese contexto, no existe un límite real para la cantidad de registros de una tabla InnoDB, por ejemplo. ¿Crees que con ForxPro podrías hacer lo mismo?

- ¿Necesitas el servidor Apache? No, a menos que trabajes con PHP o algo así. El servidor apache se usa localmente para poder interactuar con aplicaciones de tipo Web, pero el MySQL específicamente no lo necesita si vas a usar VB.Net, VB, C, C++, Java o algo así. Incluso si vas a usar Access con MySQL, no se necesita.

- ¿Necesitas ODBC? Y... si queires acceder a cualquier sistema de datos, incluyendo sistemas de archivos o tablas DBF, lo necesitas porque es lo que Microsoft inventó para eso. Además, la idea es que tengas un único recurso capaz de abrir datos desde cualquier otro programa y hacia cualquier tipo de tabla sin tener que cambiar nada más que unos parámetros según la fuente de datos. Yo no le veo tanta dificultad. Ten en cuenta que la idea es que se pueda usar la fuente de datos desde aplicaciones completamente diferentes, creadas por empresas diferentes.
Además, lo instalas una sola vez... ¿o no?

- ¿Por qué hay problemas de regionalización? Porque no todos los países y en todos los idiomas las cosas se escriben igual, e incluso ni siquiera usan la misma página de caracteres. Si las cosas cambian entre idiomas, es lógico que deba haber forma de evitar que datos iguales escritos de diferente forma generen conflictos. ¿No te parece? Programar para evitar eso es mucho más fácil de lo que crees. Pero requiere ganas de hacerlo.

- ¿Son "mamotretos" difíciles de instalar? No, bajo ninguna circunstancia. Yo puedo instalar MySQL desde cero en mi notebook, Workbench y cargar una base, recuperándola en Excel en veinte minutos. Sin ningún problema. Pero si partes desde la filosofía de que es "basura", no lo podrás hacer. Tampoco podrías jugar así ni a la payana.

- ¿Si haces todo, podrás imprimir en Excel esa tabla? Depende... ¿Tiene más de 56000 registros? Si es así, no, porque Excel no puede abrir tablas únicas tan grandes, pero Access si puede.

Volviendo a la idea del inicio: El problema no es tanto que el sistema sea demasiado complicado. Es que te has quedado en el tiempo o te has sobreespecializado en Ofimática. Si sientes que el tema te supera, entonces dáselo a alguien capacitado en quien confíes, a fin de cuentas, Galeno tampoco pasaría un examen de residencia en un hospital, hoy en día.



Edited 1 time(s). Last edit at 06/29/2011 07:39AM by Gonzalo Garcia Correas.

Options: ReplyQuote




Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.