En la tercera o cuarta instalación del sistema, tuve para variar que borrar todo y copiar el script a mano para que los usuarios beta pudieran hacer su trabajo. Esto me hizo firmarme en el phpmyadmin, y como es natural, no hay esquema de base de datos.

Este es un resumen de irregularidades notadas a simple vista, no es un análisis completo ni de normalización/estandarización.

Estas notas corresponden al numero de pantalla del zip y una descripción de 30 pantallas, que pueden descargarse en zip de aquí próximamente.

01: la instalación completa de Xomol com modulos, crea 181 tablas en lugar de 49 de drupal simple. Siendo 79 sin módulos, se nota un exceso de tablas de todos modos.

02: Son demasiadas tablas por módulo. ya había visto en elscript que no hay integridad referencial, pero 15 tablas de banners son excesivas. Y ademas, muchas columnas de tablas como usersonline tienen que ver con banners. Error fuerte de diseño, y por lo que se ve no tiene idea de normalización.

03: Claro que el store usa MAS 40 Tablas, pero ni siquiera funciona ni es multidivisas.

04: Que estan haciendo Admin metatags, admin lenguajes en usersonline ? Lo mismo que mas de 13 campos inútiles relacionados con banners. Con Razón necesita 200 k para ver quien esta en línea aunque la lógica es que se hace con 10 líneas sin problemas.

05: Instalando desde el script, hay 12484 registros, y eso que son pocos artículos. Eso hace pensar que estan mezcladas en una base de datos mal diseñada, datos a los que no se puede accesar fácil, mucha publicidad, o ambas cosas.

06: Caray, la tabla de styles tiene 1998 registros. Excesivos porque si hablamos de 3 templates. son mas de 650 parámetros por template. No solo se cometen errores de principiante (color de links igual al fondo gris/blanco en menús que se vuelven invisibles al ponerse encima del menú) sino que evidentemente no se usa la parte cascada del concepto cascada, y por lo mismo se lee de base de datos cada vez. Por lo mismo, tampoco hay caché y al ser internos, se carga cada vez. Es decir, miles de lecturas a lo tonto, y que no se cachean.

07: geostates tiene 3840 registros también yno es primoridal en un CMS. Es decir, la mayor parte de geostates y sus derivados, se usan para banners nada mas.

Es raro que use una tabla para modulos y otra para modulos desc, para 11 registros. No solo se crea solo problemas de integridad referencial y mantenimiento, sino que son demasiadas tablas para lo que realmente hace el programa.

08: En my_company_docs viene un texto que supongo se usa para algo. Me interesó el lenguaje mexican, que segun yo no existe.

09: la tabla modules resulta un ejemplo claro de porque no hay integrudd referencial y porque es inmanejable. Ademas de señalar que no sabe programar.

Campo whocanview = ,1,100,102,200 que supongo pertenecen a grupos de usuarios. Por lo mismo no hay integridad referencial, y por la coma inicial se ve que no usa los estándares normales de calidad.

10 y 11: Otro caso estúpido de la integridad referencial, es la pantalla 10. usa un código postal imposible por lo largo (100007), pero también usa un estado nahualtepec, que evidentemente no existe, lo que signifia que es una integridad referencial medio rara contra su propia tabla de 3840 registros de estado. Yconste que dice país México Ciudad aztlan. Es decir, como no hay ciudad aztlan, ni municipio de nahialtepec y el código postal es imposible, significa que sus propios datos de ejemplo, o su integridad referencial, o ambos, son basura.

12: My_Company_info Claro que definir el pais como cadenade 64 caracteres es excesivo. y claro tambien que el código postal es varchar(64), y la calle es de 64. O sea que asigna igual de espacio a TODA LA PINCHE CALLE que al código postal.

Y en la misma tabla, lo hace con otro juego de campos para el banco.

Esta tabla hace pensar seriamente que no tiene la mas mínima experiencia en diseño de datos, o como dijera El primer usuario del sistema, este tipo no sabe.

13: La tabla module_desc y su mención de mexican como llave, preocupa. Si quisiera corregirlo poniéndolo a español, pues no podría. No tiene demasiada lógica la tabla en si. Y sin integridad, menos.

14: Revisando desde la tabla los 1998 estilos de styles, uno se espanta. Cinco lecturas de base de datos, para poner el a:link ??? No solamente es ineficiente, sino confuso y de todos modos el módulo correspondiente me comentaba uno de los usuarios de prueba que puede mostrar valores ilógicos en base a CSS2 (de sintaxis)

15: Styletags es parecido , no documentado y tiene el mismo problema. No solo no se ve mucha comprensión de la CSS, sino que un servidor con 200 a 300 simultáneos se alentaría horrores por tanta lectura.

16: geo_state parece ser no normalizado. State_Country_id está mal, deberia ser country_state_id porque el padre es Country, se supone. Mal diseño.

17: Configure es otra tabla críptica. y que carajos esta haciendo “1 Site Layout” en config_type ? Incluso sin descripción aqui hay tres Campos crípticos e ineficientes.

18: banners usa varchar de 10 para fechas que incican y que terminan, en lugar del mktime. Esto da a entender varios problemas. De entrada los banners deben funcionar por dias completos y no a partir de una hora (venta especial a partir de las 21 horas no se puede), y por otro cálculo de estadísticas en base texto son mas pesadas que en base mktime. Hay que reconocer que yo dejaría campo en cristiano (por legibilidad), pero tendría dos campos mktime por las razones mencionadas.

19: La tabla content_frontpage no es intuitiva, pero el campo creation aqui es de 16 y en otros lados de 32 y 64, creo. No está normalizada y es extraño el diseño.

La llave de author_id(en el indice) no hace mucha logica porque al guest o a muchos usuarios , no va a buscar por contenido escrito por un usuario, sino lo que esta en la página principal(frontpage). Tampoco veo “order” por si son dos o mas ni fecha.

20: targeted_user en content_art es una de las cosas mas raras que he visto. Sin comentarios en un CMS porque si se hiciera target del contenido, que de por sí no es muy buena idea porque sería mas bien nivel de acceso pero esa es otra historia, el targeted debería ser por grupo y no por usuario. Notese que la creation no es mktime.

21: Esta pantalla no solo demuestra porque no hay integridad referencial, sino que no es multilenguaje, sino que lo que se escribe se captura tres veces. Esto tiene varias implicaciones sobre porqué el Esscenario dos falla. También implica un punto de vista raro de los SEO, y que los metatags de Xomol están 15 veces en la tabla.

22: La pantalla tiene como idioma predeterminado el alemán. O sea que es poco probable que se hiciera con mexicanos en mente. PROBABLEMENTE METE METATAGS en todo porque son obligatorios. Otro error de diseño. queda pendiente ver que es el default del campo

23: Logos por usuario es poco comun. Y mas raro que sean user_www_1 a 3, que no es intuitivo y tiene huecos de seguridad. No se hacen verificaciones , y pueden usarse todos los exploits tipo avatar. Verificar como Vector de Ataque de saturación.

24: En la tabla de metatags, a pesar de decir que usa texto en español el lenguaje, el metatag viene de varios idiomas. Mal diseñado, redundante y errores de concepto y de diseño, no solo por los datos basura.

25: store_module_desc da a entender que son modulos de la tienda, pero por el contenido se va mas bien a una descripción de formas de pago, o diccionario, pero de modulo nada.

26: mas de lo mismo.

27: Store manufacturers indica que no se pensó en la necesidad de dos productores de un mismo producto. Normalmente se haría con una tabla puente entre proveedores y articulos, pero aqui no lo consideraron. (Lo mas seguro es que nadie use la tienda virtual, o que metan información errónea. Limtación fuerte de diseño.)

28: mas metatags, parece que todas las tablas tienen metatags, y si son obligatorios peor tantito. Diseño raro y dificil de verificar la integridad.

29: Auch !!!! Los metatags son tipo TEXT !!!!!!!!!! (capaz que estan así en todos) y la tabla no tiene índice

30: Pues por lo menos en esta tabla tambien son text.

Que horror.
=====================================================
No tuve valor para seguir viendo, pero es evidente que David Guttmann no tiene idea de diseño de bases de datos y que es un sistema basado en publicidad.