Skip navigation links

MySQL Forums :: Spanish :: importar tablas mysql - mal diseño


Advanced Search

Re: importar tablas mysql - mal diseño
Date: July 02, 2011 01:23AM

A ver Gonzalo, te agradesco el esfuerzo de haberme respondido. Creo que no debería responderte pero estas cosas me ponen tan molesto que lo voy a hacer.
Primero: Respeco a "la verdad no les importa" tiene que ver conque no me parece que los procesos de registración pregunten tantas cosas. (y en cierto modo tiene que ver con lo que estamos hablando, o sea el sentido que esta tomando la informática) y en particular no estoy de acuerdo conque me pidan el apellido.(reconozco que debería haber sido más claro y más cortes y poner "no creo que tenga que poner mi apellido")
Por otra parte, para mi también es dificil responder con cortesía a alguien que no se ha tomado la molestia de leer con atención y comprender el post con el que debate.
A ver, reitero la importancia de la escala al tomar desiciones. Como puse en el post: "si vas a hacer un rascacielos tenés que hacer planos detallados y buenos cálculos si vas a hacer una cucha de perro no".
El programa en particular que estoy hablando, como dejé claro en el post, es una cucha de perro. No hace otra cosa más que una búsqueda y no se va a escalar. ¿entiendes?. Siguiendo tu metafora es un partido de futbol 5 de aficionados por lo tanto no tiene sentido gastarse millones para llamar a un jugador profesional para reforzar el equipo y contratar un arbitro. ¿entiendes?. Por supuesto que cuando el problema es más complejo se nesecitan cosas más complejas. ¿se entiende?. De hecho, tal como ponía en el post (no lo tengo a mano sino te haría la cita) habitualmente suelo quejarme de la sub-escalación (o sea al revés que en este caso). Por ejemplo, como ponía en el post, actualmente en mi trabajo tengo el problema de que existe una cultura de resolver muchas cosas haciendo planillas excel (por ejemplo ahora tenemos un problema con el manejo del inventario de toda la organización y estamos sufriendo el hecho de haber encarado durante años las cosas con esta filosofía). Es claro que el inventario no se puede manejar con planillas excel (que encima dos áreas tratan de manera diferente). Es obvio que a partir de cierta escala es bueno poner un dbms y es obvio que cosas como integridad referencial o manejo de transacciones (que no tenía DBIII) son buenas ideas a partir de cierta escala (¿se entiende el concepto de escala?). O conceptos ad-hoc al problema, Por ejemplo en el inventario, es importante tener trazabilidad de los registros. O sea, que cuando se mueve un objeto de una oficina a otra, no basta con modificar el registro sino que es importante hacer otro registro poniendo donde está ahora pero mantener el registro viejo y tener alguna clase de link para poder saber donde estaba antes (para poder rastrear como se han movido los objetos). Hay situaciones en la que esto no es necesario, cuando uno tiene que modificar el registro lo modifica y ya, punto (o sea en el ABM, una M es una modificación y punto, se pierde la información que existía antes.En este caso, es mejor mantenerla. O sea, las cosas dependen siempre del problema ¿entiendes?. Para el caso que motivo mi post, el punto es que yo quiero capturarme un listadito de que no tendrá más de unos cientos de registros y ya. No hay escalamiento, no hay más complejidad que eso, ni siquiera es un partido de futbol 5, es jugar con un niño en un jardín ¿juegas con los mismos criterios un partido de competencia que cuando juegas con un niñito en el jardín mientras se hace el asado?. ¿se entiende?. También en ese sentido, no es que el mysql sea "dificil de instalar", el punto es que es "dificil de instalar teniendo en cuenta que solo me quiero capturar una tablita de miercoles de unos cientos de registros".
Respecto al aspecto más técnico de tu post, que por cierto me interesa, no termino de comprenderlo. En particular y dado que el problema no lo tengo en rigor con el mysqul sino con la falta de un utilitario que me permita capturar la tabla de un modo más directo, no entiendo porque esto no es posible y porque es tanto más compleja la estructura de datos de mysql que por ej. la del foxpro. Obvio que el DBMS mysql es más complejo que el foxpro que a su vez es más complejo que el dbIII (e, insisto, eso esta bien dependiendo de la escala del problema ¿se entiendo a lo que voy?), ahora bien ¿que hay de las estructuras de datos subyacentes?, porque en algún maldito lado tienen que estar los datos, en particular el maldito listadito de escuelas de unos cientos de registros. ¿es tan complejo como para que un utilitario no los pueda comprender en forma directa?. Obvio tiene que manejar estructuras más extrañas que lo que era el dbIII, por ejemplo la citada integridad referencial si es que la tiene(me imagino, porque nunca trabajé con mysql, lo pongo como ejemplo), o índices más sofisticados(porque a pesar de todo, siguen teniendo índices ¿o nó? pero como sea en algún lugar del archivo tienen que estar el tonto listado de escuelas.

, o sea, te cito:
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.


¿puedes extenderte sobre esto?, me interesa desde el punto de vista teórico, más allá del listado de escuelas.

Options: ReplyQuote


Subject Views Written By Posted
importar tablas mysql - mal diseño 1481 fernando la verdad no les importa 06/29/2011 12:41AM
Re: importar tablas mysql - mal diseño 726 Gonzalo Garcia Correas 06/29/2011 07:37AM
Re: importar tablas mysql - mal diseño 498 fernando la verdad no les importa 07/02/2011 01:23AM
Re: importar tablas mysql - mal diseño - solucion parcial 747 fernando la verdad no les importa 07/02/2011 04:30AM
Re: importar tablas mysql - mal diseño posdta 621 fernando la verdad no les importa 07/02/2011 02:12AM


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.