13 respuestas en este tema

[Desart]

Propongo a los compañeros la siguiente idea, por que no creamos, una serie de temas relacionados con tablas especificas, en que pongamos  el nombre del campo, tipo, tamaño y una pequeña descripción y o aclaración, por ejemplo empezar con un tema llamado Estructura clientes, que ira como no sobre la tabla clientes y pondríamos más o menos (es una idea)    CodCli,  AlfaNumeric, 20 , Guarda el código del cliente, alfanumérico, para que admita letras y números  Nomcliente,  Alfanumeric, 40, nombre del cliente  Etc...    Como veis puse alfanumeric, puede ponerse String, etc.. no importa en este caso el tipo de base de datos y nos ayudaría a mejorar nuestras bases de datos, actuales y en un futuro, enseñarnos nuevas posisbilidades etc, tambien podrimaos poner indices y campos con autogeneradores, etc..

[egostar]

Muy interesante y educativa propuesta.

Salud OS

[eduarcol]

Tambien añadiria que cada tabla fuera acompañado de su DDL para poder generarla de forma facil para el interesado.

Propongo que se abra una division en el foro que se pueda llamar EJEMPLO DE TABLAS y cada tabla que tenga su respectivo hilo para las discusiones

[Delphius]

Hola,
Disculpenme pero no entiendo. ¿Se está buscando intentar hacer algo como DatabaseAnswers?

El mayor problema que le veo a la forma propuesta de encararlo es que no se entenderá nada porqué estará todo descolgado. El diseño de una base de datos responde a un análisis del contexto, del ambiente o negocio... no debería verse tabla por tabla, tratando de hacer encajar un ejemplo a un caso práctico; y por sobre todo real life que en ocasiones hasta por cuestiones de diseño, operatoria, y eficiencia nos vemos "obligados" a romper con las reglas normales, y la teoría termina siendo destrozada.

Más bien considero, si es que les parece oportuno que a estos temas de diseño y análisis de bases de datos y DERs los veamos caso a caso, de forma particular *, y los discutiéramos en el foro de Base de Datos (podríamos ver la posibilidad de abrirle un sub-foro como "Diseños DER").
Ahora bien, si la idea es tratar de desarrollar una especie de guía o tutorial lo adecuado sería iniciar uno en el foro Manuales o Tutoriales.

* La experiencia dirá tarde o temprano que no hay dos bases de datos iguales.

Disculpen que les vaya en contra... es que no lo veo práctico la forma en como se lo propone. Una tabla no puede ser vista como algo atómico, ¡está viva... relacionada a algo y ese algo repercute, quieran o no, en su diseño!

Saludos,

[Desart]

hola compañeros, agradezco vuestras opiniones, pero debo aclarar, que mi idea original es que funcione independientemente del lenguaje usado y del tipo de bases de datos usado, aclarado esto, se que cada programa usa tablas/campos muy específicos, que en programas estándar no se usarían, pero para que entendáis mi idea, os pongo un ejemplo de lo que digo:

Tenemos un campo CodigoPostal, que lo ponemos numérico o alfanumérico,  con un largo de cuantos caracteres 5,6,10. esto es lo que deberíamos discutir, por que aquí en España el código postal es un número de 5 caracteres, pero yo lo represento de 6 por que me queda más claro con el separador de millares (es mi opinión claro), pero puede resultar que en vuestros países tenga letras o sea de 8 o más caracteres, o un formato diferente.

En cuanto que tipo de campos poner, los estándar y lo que no, el motivo es muy claro seguro que a vosotros al igual que a mi y a otros compañeros, habéis pensado, este campo lo hubiese hecho de otra manera, más largo, de otro tipo, o me falto esto o lo otro, etc..

El otro gran problema es la programación de gestión, es tan diversa que cualquiera de nosotros, puede haber programado para cosas tan dispares como hoteles, casas de alquiler de coches, talleres, clínicas medicas diversas, bares , restaurantes, oficinas, etc.

En mi caso he programado desde el dbase IV, turboc, clipper, Qbasic y ahora el Delphi, para cosas tan dispares y diferentes como, una tienda de revistas, un video club, un taller, una agencia de contactos, asadero de pollos, una tienda de muebles un programa para tiradas de cupones, programa de ventas de cupones, empresa de limpieza, jardinería y control de plagas y ahora para el programa de mi empresa de fabricación de productos de limpieza.

Siento la charla pero quería que se entendiera mejor mi idea.

[Delphius]

Hola Desart,

Pareciera ser como que has tenido mi opinión como un ataque, no es esa mi intención sino mostrar que esa línea que propones no va a resultar tan bien como lo propones, y presisamente por esas cosas que has dicho: en cada lugar, caso particular, se dirá que es A, B, C o hasta Z.
Esa pluraridad de visiones, que no necesariamente van a ser erróneas o mal pensadas, hace difícil que podamos llegar a un sano debate y a un concenso.
Te pongo un ejemplo que comenté hace unos cuantos días en otro hilo: en algunos lugares existe una norma que impide guardar y tratar los números reales en un formato de coma flotante sino que deben trabajarse y almacenarse con una representación numérica entera. Si luego vienes tu y dices que no, que eso se puede hacer más fácil con algún tipo de dato flotante como ser los NUMERIC(p,s) o DECIMAL(p,s), o DOUBLE y nunca has tenido un problema... ¿Quién tiene razón?
En realidad AMBOS tienen razón, y para X tiene que ser así, y para Y será asá.

Es bastante difícil llegar a un diseño homogéneo, estándar, en el tema de base de datos. Como he dicho; cada diseño es único... cada base de datos es única.

Yendo al ejemplo que expones, no es lo mismo la tabla Clientes diseñada para un ERP que la tabla cliente que pueda esperar un sistema que utilizará el Don almacenero de la esquina.

Por eso yo indico que en todo caso veo más sano y práctico discutir DER a DER, Diseño por Diseño, caso a caso y no intentar comparar y equilibrar dos o más tablas que están pensadas para contextos y situaciones diferentes. ¿Porqué? Porque precistamente, eso: NO TIENEN COMPARACIÓN. Son casos diferentes. Si disponemos de un sub-foro en Base de datos que se discutan y pidan guías, consejos, o sugerencias para encarar el diseño de una base de datos, apoyándonos en un DER (que dicho sea de paso, es independiente de los motores... que es una de tus preocupaciones) podríamos allí si hablar y se podría apreciar justo lo que dices: las diferencias en como encaramos nuestos diseños... En este escenario es fundamental aclarar bien las normas, leyes, o restricciones técnicas y/o operativas que condicionen al caso de ese modo se puede guiar las experiencias de cada quien y luego queda en la responsabilidad del interesado en poner en práctica y rescatar lo que más le conviene.

Pero no es lo mismo que todos analicemos un mismo contexto, que todos hablemos desde una pluraridad de conceptos tratando de explicar un elemento que quizá podríamos encontrar en común (como por ejemplo, la tabla Clientes que comentas) que es lo que propones.

Incluso me atrevo a decir que dos diseños de base de datos diferentes para un mismo contexto no implica que una sea peor y la otra superior... Cada quien la expresa según una INTERPRETACION DEL CONTEXTO. Mientras ambos diseños logren responder a los requisitos y se complementen con sus respectivos aplicativos el análisis de cual es mejor o peor queda sobrando.

Por ello yo digo que de todas las cátedras, la más difícil de evaluar es Bases de Da0tos... ¡Si supieras de la cantidad de veces que se ha discutido en mi clases por los diseños! NO SE DEBEN COMPARAR DOS BASES DE DATOS.... NO SE PUEDEN TROZAR Y COMPARAR SUS TROZOS.

Desart, no lo digo de mala gana, sino para un bien... lo que pides es, haciendo cierta analogía con lo culinario, una descontrucción. Una tabla pierde sentido si no se la ve en contexto... o vez el todo, o no tienes contexto. La reconstrucción final no será la misma porque la cantidad de los ingredientes y la forma de preparación está calibrada para cada caso.

Quisiera que los demás se expresasen también, a ver que opinan.

EDITO: Aquí justo tiene una muestra de lo que digo. ¿Habrá otra manera de enfocarlo lo discutido allí? Por supuesto... Estoy seguro que si alguien quiere explotar aquella propuesta que hice lo hará. ¿Funciona lo que propuse Si... si se dispone de lo necesario para ello. ¿Viste como comenzó el hilo y cómo se fue cerrando? ¡Que distinto hubiera sido si cada quien se pusiera en su lado, menudo lío!
¿O que te parece esta otra discusión? 

Saludos,

[Desart]

Hola Delphius, no no tomo tus comentarios como un ataque y respeto tú  opinión de hecho suelo ver diferencias de opinión muy a menudo y creo que es bueno, siempre y cuando no se tomen como algo muy personal, mi intención con mis repuestas nunca ha sido defender a capa y espada una propuesta ni una idea, lo que pretendo, es prender seguir adquiriendo información, soy de los que aprendo cuando me enseñan, cuando me abroncan y cuando me equivoco (de toda la vida).
Tienes toda la razón, cuando dices que  cada base de datos debe de ser implementada a la aplicación correspondiente adaptándose a esta y no al revez (si te entendido bien) y mi intención nunca ha sido crear bases de datos únicas, he visto los links que adjuntases y las respectivas discusiones, pero es lo que te comentaba, cada uno tiene una forma de verlo y en este caso sobre unos casos muy determinados.

Como muy bien sabes la programación de gestión es lo suficiente mente amplia, como para escribir miles de foros sobre cada programa con sus bases de datos, cosa que no pretendo, pero por que no tener una pequeña base de conocimiento, con estructuras lo más completa y claro esta detallando la utilidad de cada campo, para que cuando cual quier compañero tenga que empezar un nuevo proyecto, cree la estructura de su base de datos, teniendo más claro que campos le puede hacer falta y cual puede ser su mejor opción.

sigo diciendo que esto es una idea, incluso si se siguiera adelanta, creo que primero deberíamos, acotar grupos de campos repetitivos que usa varias bases de datos, como pueden ser:

País, Código postal (o Equivalente), Población y  Provincia.

Persona de contacto, Puesto, Móvil, Exención, Email, Fecha de cumpleaños.

Banco, CCC( Entidad, Oficina, Dígito de control,  número de cuenta), teléfono.

Estoy seguro de que cada uno tendrá grupos de este tipo, que diferira o no de los mios, etc..

Si mañana entrase a trabajar en un hotel y tuviese que hacer un programa para este, me vería un poco perdido inicialmente, si tuviese una base de datos donde ver el ejemplo de la estructura super detallada, me permitiría aclararme un poco más las ideas, luego claro esta cogería sólo lo que me fuese útil , para la aplicación que tuviese que hacer, y si añadiese algo, lo que haría es añadirlo a las estructuras del club y los motivos de por que estos añadidos, el día de mañana, alguien tendrá que realizar algo parecido y le podrá ser útil o no.

Estoy de acuerdo también que debemos respetar la normas de cada País, no lo discuto, exceptuando en programas que puedan ser internacionales, pero si yo que vivo en España tengo un cliente en el país XXXXX y su código postal es de 7 dígitos, mi aplicación tendrá un problema ya que esta diseñada sólo para 5, esto es el tipo de cosas que se podría evitar de tener que estar modificando a posterior.

[Desart]

continuo aparte, para intentar adentrarme un poco más en la idea, siguiendo el ejemplo del código postal, que en España es un numero de 5 cifras, puede ser que en Chile se un alfanumérico de 7 y en estados unidos un numero de 10, ojo no tengo ni idea solo discurro (imagino libremente), lo lógico seria un alfanumérico de 10 , ya que nos permitiría aceptar los tres casos.


Bueno no parloteo más, de momento

[egostar]

Hola

¿ No será mejor que primero se planifique el alcance del proyecto antes de diseñar la base de datos ? Quiero decir que entiendo las posturas de Marcelo y de José Luis, sin embargo, la idea de poder 'tropicalizar' un sistema me parece un reto interesante, seguramente no lleguemos a una estandarización al 100%, pero el hecho de contar con un diseño que sea de fácil adaptación a la región que sea siempre será bien recibida.

Yo creo que con algo de trabajo pero si se puede.

Salud OS

[Delphius]

Hola Desart,

Si la intención es que cada uno vaya aportando info sobre porqué y como estructura una base de datos brindando datos sobre ciertos aspectos técnicos/legales de porqué se hace así o asá estoy de acuerdo. Se puede hacer eso.

Pero para llegar a ello debe llegarse a una clara definición del contexto, marcarse límites bien claros y, porqué no ciertas reglas a las que nos tuviéramos que atender. Y eso lo veo un tanto complicado... lo que yo entiendo por un CRM, por ejemplo, puede que sea corto con la apreciación de otros. No va a ser nada pero nada fácil llegar a un concenso.
Por ello es que yo sugiero que es más válido y fácil de tratar si se discutieran y debatieran las cosas caso a caso.
Además esto requiere de mucha preparación (en lo legal por sobre todo) y me temo que no muchos estamos en la posibilidad de ofrecer información que pueda ser útil como para que otros comprendan el porqué en tal Pais/Provincia/Departamento/Intendencia se hace así y no asá porque simplemente somos informáticos, y no abogados, o contadores, o... vaya a saber que más.

El sitio DatabaseAnswers ofrece una amplia cantidad de DERs que uno puede consultar y tener como guía para encarar sus propios diseños. No creo que valga la pena gastar más esfuerzo en legar a algo como eso. Yo preferiría pasarles el enlace al sitio y aclararles: "mira, allí tienes algo como para orientarte; pero por favor no los copies... estudia y analiza tu caso y luego saca y formula tus propias ideas". Y de hecho, eso hago muy a menudo en YR cuando veo preguntas sobre "¿Cómo estructurar una base de datos para un <ponga-aqui-el-emprendimiento>"? o "¿Que campos son necesarios o me faltan en la tabla X para un <ponga-aqui-el-emprendimiento>?"

Lo que te dije a ti, se los digo a ellos. Algunos lo toman a bien, otros directamente prefieren llamarse a silencio y el resto prefiere mandarme al diablo.

Lo que si veo posible de hacer y que podría ser más ordenado y fácil de seguir es la de disponer una especie de "Wiki" a modo de artículo sobre algún tema o apartado. Cada uno podría iniciar una nueva sección aportando info sobre aspectos técnicos, legales y/o operativos sobre como encarar ciertas cosas dentro de una base de datos, tabla y/o cualquier otro objeto que pertenezca a una base de datos pero puntualizando que hace referencia a X lugar del mundo.
Es decir aportar info más no invitar al debate y buscar que unifiquemos puntos de vista.... repito y sostengo: ESO NO VA A FUNCIONAR.

Por ejemplo, el caso que comentas del Código Postal. Se podría armarlo así:

Tema: Código Postal.
País: Argentina.

Descripción:
En Argentina durante años se ha estado usando un Código Postal de 4 dígitos, y el problema de éste es que hace más difícil determinar a que lugar hace referencia ya que no existe cierta correspondencia geográfica. ¡Los códigos se iban asignando según nacían las ciudades!. Al día de hoy convivimos con el sistema viejo y uno actual que si aplica geogeferencia.
Esta georeferencia nos llevó a elaborar un código postal que consiste en una serie de números y letras que se compone de:
Provincia - Localidad (o Departamento) - Calle - Numero de Casa

Así es que se llega a un código de 8 dígitos de forma: LNNNNLLL
Siendo L una letra, y N un número.
La primera L identifica la provincia, esta letra corresponde al viejo sistema de patentes Argentino en el que a cada provincia se le daba una letra, para ejemplo a Salta le dieron la A.
Los NNNN consiste en el viejo código Postal, a Salta, Salta (la capital lleva el mismo nombre) le fue otorgado el 4400. Entonces ya tenemos A4400.

Las tres últimas letras hacen referencia a la manzana o cuadra, y si alguien quiere estar interesado en enviarme un cheque con u$s 500 puede hacerlo: A4400EFX; se reciben también cartas de amor de chicas bonitas. Como se vé, EFX indica la cuadra (la calle, y número de casa).

Discusión:
El problema del CPA es que sólo rige y es válido para aquellas ciudades que tengan más de 500 habitantes. Las que tienen menos, se ven obligadas a "unificarse" y se les atribuye un mismo CPA.
La forma de escritura establece que no debe escribirse guiones, espacios ni cualquier otro carácter o símblo fuera de las letras y números. Se sugiere y recomienda emplear MAYUSCULAS, pero si es una obligación el uso de letra de imprenta.

Referencia:
Para mayor información consulte el sitio del Correo Argentino.

Propuesta:
A nivel de base de datos se sugiere que el campo tenga un tipo alfanumérico limitado a un máximo de 8 caracteres. Como la mayoría de los motores cuentan con los tipos genéricos y estandarizados, se sugiere el uso de CHAR o VARCHAR.

En vista a que convivimos con el sistema viejo y el nuevo, y a que la gran mayoría de la población desconoce el CPA es que no se estila forzar al usuario emplear uno u otro por ello se considera de mayor utilidad la posibilidad de VARCHAR() ya que aprovecha mejor el espacio.

A todo esto, el siguiente script:

ADD FIELD CAMPOPOSTAL VARCHAR(8)

Sistema:
A nivel sistema debería llevarse un control bastante riguroso. En primer lugar debe controlarse que se ingrese uno u otro sistema. Quizá por cuestiones de sencillez lo más adecuado sería disponer de un RadioGroupBox para elegir por uno u otro. Dependiendo de dicha elección el sistema puede elegir la regla a aplicar.

Regla 1. Sistema viejo:
Obligado a utilizar 4 digítos. Es decir no se permiten 3 o menos.
Sólo números.
Controlar que no exista cero a la izquierda.

Regla 2. Sistema nuevo:
Obligado a utilizar 8 caracteres.
Primer caracter debe ser alfabético.
Caracteres 2 a 5 deben ser numérico. Corresponder a Regla 1.
Caracteres 6 a 8, alfabético.

Como en la base de datos se hará uso de VARCHAR() en dicho campo habrá 4 o 8 caracteres. Como sugerencia, y a modo de debate y análisis para quien lo considere se podría añadir un campo extra para indicar a que sistema de correo hace mención:

ADD FIELD TIPOCODIGOPOSTAL INTEGER

¿Se entiende más o menos?
En ningún punto se les indica y se busca limitar a otros, sólo se habla que en Argentina utilizamos este sistema. Luego si alguien más quiere continuar el tema hablando desde otro lugar puede añadir una nueva sección o apartado.

Saludos,

[Desart]

Hola egostar, me parece perfecto tu planteamiento.


En cuanto a ti Delphius te aplaudo sinceramente por la información dada, me he quedado boquiabierto , lo que yo comentaba no llegaba a tanto, pero lo que yo proponía era algo como Alfanumérico de 8 dígitos (Argentina), no creo que nos haga falta una descripción tan detallada, aunque como te comento me quito el sombrero ante ti maestro, El planteamiento que me hago, para haber abierto este tema, es vivimos en la era Global, las empresas cada vez se interrelacionan con otras extranjeras, con mucha más facilidad, y por lo tanto nuestro arquetipos más o memos estándar, van quedando desfasados, a muy corto plazo será necesario modificar o crear nuevos programas para que se adapten no soló a formatos de nuestro país y por ahí es por donde voy, si a esto le sumas el tema de que muchos que empiezan no tienen mucha idea básica de gestión.

[Delphius]

Hola,

Desart, no soy un gran maestro... y ni te creas que se mucho de sistemas de gestión ¡que en realidad no tengo ni la más paupérrima idea de eso!
Es que considero que no basta con decir "En Argentina el código postal es de 8 caracteres así que amigos el campo tiene que ser un CHAR(8)" porque no es correcto, ni adecuado. Como he dicho en el ejemplo anterior en Argentina convive el viejo sistema con el nuevo y debo decir que casi nadie utiliza el nuevo... ¡si hasta las empresas para enviarte las boletas no lo usan! Es que nos hemos acostumbrados a los 4 dígito y es más fácil recordar un 4400 que un A4400EFX. Sólo una boleta llega a mi casa con el nuevo sistema postal.
Entonces es fundamental explicar como, porqué, cuando, etc.... sobre todo como dices que estamos en una época global.
A lo que apunto yo es que podemos formar esa especie de Wiki con información que podría ser de utilidad para cuando nos vemos metidos en situaciones en la que debemos llevar a cabo un sistema que será utilizado en un lugar diferente, con una legislación diferente, con un sistema diferente, ¡todo diferente!

Pero no podemos limitar, y condicionar, y por sobre todo llegar a un acuerdo y decir... "bueno muchachos... en vista que en el código postal más esotérico, raro, y largo está en CuloDoMundo tenemos que hacer los campos de nuestras bases de datos del tamaño máximo".

Hay tanto que considerar y poner en juego que no veo práctico eso. Lo único que haremos es condicionar y limitar a otros y que se encaje a un diseño que quizá les sea contraproducente.

Es mejor directamente ofrecer una descripción bien formal de las cosas y dejar que cada quien lo analice y de allí vea como ajustarlo y llevarlo a la práctica en sus propios desarrollos.

Lamentablemente, por más flexibles que pretendamos hacer nuestros sistemas siempre habrá algo que nos rompe esa flexibilidad. Y eso nos toca y rompe las coronillas... y otra vez a volver a la mesa de dibujo. ES INEVITABLE, es parte de nuestra concepción sistémica: todos sistema tiene sus ciclos y tiempos de vida, debe aprender a morir y adaptarse. No podemos estar previendo cada cosa... por que así el sistema tendrá una consistencia tan blanda, por más rígida que parezca, como una gelatina que basta una metida de cuchara para cortarla.
De que necesitamos cierta flexibilidad eso no lo discuto (y es algo que nos los recuerda Tao con su frase "Lo rígido y duro se quiebra, lo flexible prevalece"), pero que no se nos suba a la cabeza porque al final tendremos un sistema que apunta a todos lados pero termina tirando perdigones y no balas precisas, certeras y rápidas (Algo que me lo recuerda Jeff Valdez: "Los gatos son más listos que los perros. No puedes conseguir que ocho gatos empujen un trineo por la nieve").

Procesos de Reingeniería hubo, hay y habrá. Bienvenido al Caos Desart... bienvenido a la crisis del software 

Saludos,

[Desart]

socorro estoy en crisis

[Sergio]

Yo queria proponer algo similar, pero mas parecido a lo que comenta Delphius, ya que respecto de estructuras de bases de datos, sería una gran locura.

Mi idea es un subforo con post del estilo: "Codigo postal, España" y dentro toda la explicación.

Realmente lo pense para "Numero de cuenta, España" ya que estos códigos incluyen dígitos de control y esas cosas y es muy complicado localizar esa información.

Mi propuesta seria incluir para cada país, la información sobre: Códigos de identificación de empresas o particulares (NIF y DNI en España), Números de cuenta (incluyendo códigos intrernacionales como SWIFT y IBAN), Tarjetas de credito (existe tambien algoritmo para comprobar que los números son coherentes), códigos postales...

Tambien existen formatos de ficheros especiales que podría incluirse: En españa todos los bancos admiten un único formato para enviarles remesas de recibos o de efectos comerciales (CSB19 y CSB48) y otro para recibir los extractos de las cuentas y poder "puntear" la contabilidad -ver que movimientos contables aparecen reflejados en el extracto del banco- que tambien tengo por aqui.

Si los moderadores están de acuerdo, yo me comprometo a volcar todo lo que tengo deformatos de España, y por cierto, estaría MUY interesado en lo mismo pero de Chile.