Tablón de anuncios - Optimización de la base de datos

.
22.3. Necesitar entender por qué, no es problema en absoluto. Los niños únicos siguen ciegamente reglas simples, y usted ciertamente no es uno de ellos.
.
23. Confirmado:users.total_bulletins es redundante; se puede derivar. Eliminado.
.
24. Todos sus PK son Id. ¿Aún no te has cansado de perderte en el código? Olvídate de pegar Id iot PKs en todo lo que se mueve, averigüemos cómo sus usuarios Identificar sus Entidades; qué Entidades son verdaderamente Independientes, y las otras que dependen de Entidades Independientes.

24.1. Nunca use Id o cualquier forma de este tipo. Cuando sea un PK, utilice el formulario completo.

24.2. Llame a location_id, location_id, donde sea que esté, incluida la tabla PK. La excepción es cuando necesita mostrar el rol. Esto quedará claro en el Modelo de Datos.
.
25. No tiene integridad referencial declarativa, no definida Llaves extranjeras. Esa es una mala noticia por muchas razones diferentes. Una vez que se aclaren estas preguntas, agréguelas. DRI significa que tanto como sea posible, si no toda, la integridad se declara en SQL. El estándar ISO/IEC/ANSI SQL permite esto, pero el extremo del mercado de software gratuito no proporciona el estándar y se está poniendo al día lentamente. Significa que el servidor no permitirá que se agregue una fila en la tabla FK a menos que el PK exista en la tabla principal. MySQL proporcionó recientemente DRI para claves externas. Para FK, consulte ▶ este artículo◀ .

25.1. Para las restricciones CHECK y RULES, deberá implementarlas en el código.

mis claves foráneas son como, users-id(fk) =users.id(pk) No estoy seguro de cómo agregarlas aparte de lo que he hecho, pero ciertamente lo haré una vez que sepa cómo hacerlo.

Veinticinco. Comentarios anotados. No soy un especialista en MySQL. Sí, esos son los problemas que tienes que resolver por ti mismo. En general, según mi lectura, MySQL no tiene piernas; para cualquier cosa SQL-ish, necesita InnoDB.

.
27. Dado:He repensado los requisitos de clasificación para el boletín. Los usuarios pueden ordenar cronológicamente, fácil, tiene sentido. Los usuarios pueden ordenar los boletines por la fecha de la última respuesta al boletín. Entonces podemos olvidarnos del rango y debería ser realmente fácil ordenar los boletines cronológicamente por el momento de su última respuesta. ¿Cuáles son tus pensamientos?

Problemas abiertos

(Cero)

Modelo de datos

Bien, asumiendo que no tiene problemas con el ERD e implementando todos los problemas cerrados, modelé los datos y preparé un quinto modelo de datos 09 dic 10 para su revisión. Definitivamente necesito mucho más comentarios, preguntas, etc., sobre esto. Tengo dificultad para aceptar que ya está hecho. Probablemente sea mejor comenzar a escribir código real para sus áreas problemáticas.

Enlaces

▶Enlace a notación IDEF1X◀ Realmente necesita leer y comprender esto antes de leer el modelo de datos.

▶Enlace a los datos del quinto boletín Modelo◀ El diagrama de relación de entidad está en la primera página, seguido del Modelo de datos .

• Las claves son IDEF1X bastante directas (excepto por UserId que proporcioné como contrapunto); lo que significa monedero de claves relacionales. No mejorado y no optimizado para consideraciones físicas. Antes de rechazarlos, primero obsérvelos, regístrelos y evalúelos. Por supuesto que podemos añadir Id iot keys, pero antes de hacer eso, asegurémonos de entender lo que vamos a perder.

• Observe los Identificadores (líneas continuas) según el documento de Notación. La columna vertebral, la vértebra del sistema es Location ... Bulletin ... Response .

• Tenga en cuenta que Keys en realidad implementa muchas reglas comerciales.

• Observe la jerarquía natural que he representado. Vea si tiene algún significado para usted.

• Las frases verbales son realmente importantes; mira si significan algo.

Comentarios sobre el primer modelo de datos y respuestas

Una pregunta que tengo es que la clave principal de la ubicación se usará para formar la clave principal secundaria (están unidas por una línea sólida). Realmente no entiendo ese concepto

• ¿Qué es un buen identificador para boletín? , qué usan naturalmente sus usuarios para identificar un boletín...
• "¿Has visto el boletín de Virginia FO ayer?",
• "Sally de Washington escribe buenos boletines", etc.

¿o por qué no existe esa relación entre el usuario y el boletín?

• Según la intención indicada más arriba, dado que ahora he mostrado la calificación como una tabla y cuál sería la representación, una vez, la eliminaré

• Creo que Permiso debería ser una Entidad.

• Bulletin PK ahora es (StateCode, Town, UserId, SequenceNo) . Para ser claros, SequenceNo está dentro de StateCode, Town, UserId :serán las 5 para el quinto boletín de Sally sobre MO/Billngs FO.

• Tenga en cuenta que la configuración del usuario BulletinsPerPage ,etc, son 1::1 con User , por lo que están en User; la tabla secundaria sería incorrecta.

• Errores tipográficos corregidos.

Comentarios sobre el segundo modelo de datos y respuestas

• Los PK para ambos Bulletin y Response han sido cambiados para reflejar (7). BulletinNo y ResponseNo han sido reemplazados por BulletinDate y ResponseDate (que solía ser CreatedDate ), para permitir múltiples respuestas por User por Bulletin .

Comentarios sobre el tercer modelo de datos y respuestas

Confía en que tuviste un buen descanso.

1. Hace al menos 30 años (que yo sepa), los gigantes de la industria tenían este debate. Los nombres son siempre singulares. Las tablas son sustantivos. Las frases verbales son verbos. Esto no se limita a las convenciones de nomenclatura de db, se aplica a documentos, tesis, disertaciones, etc. Puede tener 5 conclusiones al final del documento, pero la sección o el título del capítulo, tanto en el ToC como en la parte superior de la página es "Conclusión".

   Después de luchar contra ellos durante toda la universidad, tan pronto como comencé mi primer trabajo de programación remunerado y vi la importancia de las reglas en el mundo real, a diferencia de los argumentos teóricos que teníamos en la universidad, lo dejé como un desperdicio. de tiempo. Todo ese tiempo y energía que desperdicié fue liberado para hacer un trabajo productivo. Desde entonces, no cuestiono a los gigantes; solo acepto Que sus mentes son más grandes que las mías. Es como aceptar las Normas, o comportarse dentro de la ley, o de Dios. No tengo muy, muy buenas razones para hacer algo ilegal.

   De todos modos, la facilidad de lenguaje (discusión, SQL, documentación) que es compatible con tales reglas no puede explicarse adecuadamente; a medida que escriba más y más código SQL, se volverá más claro.

   Siempre eres libre de usar lo que quieras. Solo entrego en singular.

2. Bien por mi.

   Pero debe tener en cuenta que esos dos elementos, en la secuencia identificada (un índice único no PK o clave alternativa) se requieren universalmente para establecer la singularidad de una persona. Eliminarlos resultará en dos cosas. Primero, ya no podrá identificar la unicidad entre Users (y por lo tanto puede tener filas duplicadas). En segundo lugar, el AK se vuelve no único, una entrada de inversión.

3. El punto es (al contrario de una de las publicaciones), cualquier columna que sea 1::1 con el User PK, debe residir en User . Todos los ajustes de preferencias. Desde que limpiamos las InterestedLocations y InterestedCategories , solo conozco BulletinsPerPage restante; pero estoy seguro de que hay otros. IsPreference2 es un ej. de un booleano;NumPreference3 es un ej. de un entero. Etc. Puede decirme cuáles son las Preferencias reales.

   (Probemos eso en plural:... cualquier columna que sea 1::1 con los Users PK, debe residir en Users . Simplemente no lo hace por mí, me obsesiono con el inglés roto y soy un poco preciado con mi lengua materna).

   Modelo de datos actualizado.

4. Excelente. Avísame cuando te sientas cómodo con eso y te daré el modelo físico.

   ¿Qué hay de las frases verbales?

Comentarios del 6 de diciembre de 10 a las 20:38 EST (pequeñas actualizaciones)

.
28. Donde solo hay una aparición de PK como FK, por supuesto, el nombre de la columna FK es el mismo que el nombre de la columna PK. Sin embargo, cuando hay más de una occ del FK (echa un vistazo a ResponseRating ), hay tres UserIds ), necesitamos diferenciarlos. En la terminología IDEF1X, esto se denomina Roles. El Rol del User quién emitió el Bulletin es Issuer , y así. Obviamente, es mejor usar ese nombre y mantenerlo consistente en toda la jerarquía (no UserId en Bulletin y luego cuando lleguemos a Response , donde hay dos y se exige una diferenciación, cámbielo a IssuerId . Pensé que podrías tener un problema con eso; en las primeras etapas, el uso es Issuer.UserId para que quede absolutamente claro que es UserId como FK, y el Rol es Issuer; cuando llegamos al modelo físico, se simplifica a IssuerId .

Del mismo modo, tenemos muchas columnas DateTime (Date para abreviar si lo desea; de lo contrario, Dtm), que deben diferenciarse.
.
29. ¿La notación IDEF1X no tenía sentido?

• El PK de cada tabla está arriba de la línea, en el orden especificado.
• Recuerde que llevamos las PK de las tablas principales de todos modos y, si tiene sentido, usar esas FK para formar la PK secundaria.

• Para Bulletin :

  • La ubicación FK (StateCode, Town) para el que se emite
  • El UserId del Emisor
  • y la fecha y hora en que se emitió, para que sea único.
  • por lo tanto (StateCode, Town, IssuerId, BulletinDate)`

• Para eliminar todas las ResponseRatings para este Bulletin , utilice WHERE = sobre esos cuatro Bulletin columnas

.
30. Porque (State, Town) es el PK de Location , llevando donde sea. Y forma parte del Bulletin PK, por lo que cualquier tabla dependiente lleva esas columnas porque llevan el Bulletin PAQUETE.

Previamente habíamos identificado que (State, Town) es el PK, lo dejaré como está Consulte (38) para cambiar.

.
33. Vale la pena discutir. Sí, si lo va a mostrar cuando (por ejemplo) muestre Responses y los usuarios entienden UserName . No, si tiene 30 bytes y también hay un UserId único de 4 bytes . La idea es tomar estas decisiones conscientemente, consciente de lo que está renunciando, cuando eventualmente decida que una clave de 30 bytes de 6 columnas es demasiado engorrosa para migrar a los niños.

• Dije al principio que usaría UserId como un típico Id Pk, porque se transporta/migra a varias tablas secundarias.
• Podemos dejar cómo se crea para más adelante. Pero es una PK sustituta pura.

.
34. No hay problema. Category ya lo tiene Cambiaré Order a ListOrder .

.
35. Por supuesto. Según lo que he leído y escuchado, estoy muy contento con él. Pero me gustaría más ida y vuelta para lograr cierta confianza, antes de escribir el código. Alternativamente, véalo como una experiencia de aprendizaje y acepte que el modelo y el código pueden cambiar más adelante. ¿Le gustaría que produzca el Físico ahora? Si me da alguna y todas las correcciones, publicaré la próxima versión. Espero preferencias en User . Además, ejecute rápidamente las funciones y compruebe que tiene todas las columnas que necesita.

Mire algunas de las otras respuestas, con el propósito de aprender e interesar.

.
36. Uniones. Solo únete en cuatro tres columnas en lugar de una. SQL es engorroso con las uniones, y la nueva sintaxis que se suponía que lo haría más fácil, en realidad es más engorrosa. Mis codificadores nunca escriben uniones:ahorramos tiempo y errores tipográficos. Tengo un proceso que, dadas dos o más tablas, generará el código con todas las columnas y uniones. No sé lo suficiente de MySQL para convertir eso por ti.

Modelo de datos actualizado.
.

Comentarios sobre el 8 de diciembre de 10 a las 20:49, cuarto modelo de datos y respuestas

.
Consulte la sección anterior inmediatamente anterior, hay pequeñas actualizaciones.

IDEF1X:Tu velocidad está bien.

Tenga en cuenta que el niño siempre "hereda" el Parent PK, como un FK (ya sea línea continua o discontinua), de lo contrario, no hay relación entre ellos. Al usar estas columnas que existen en el niño de todos modos, para formar el niño PK, llevamos el significado (y esa es la diferencia entre sólido y roto). Y así no necesitamos buscar un Identificador independiente para el niño. El poder relacional de este método se aclarará más adelante, cuando esté programando.

El apartado que nos ocupa es sobre Identificadores :natural vs antinatural; significativo vs sin sentido. Más adelante verá cómo podemos usar la capacidad relacional del motor, cuando la PK secundaria se forma a partir de la PK principal. (¿Tu apellido no es el mismo que el de tu padre?)

También es importante comprender las bases de datos relacionales y su capacidad. Eso se pierde cuando nos acercamos a la base de datos (por ejemplo) desde una perspectiva orientada a objetos y la tratamos como una ubicación para hacer que nuestras clases sean "persistentes". Por lo tanto, intentaremos aprender y usar términos relacionales. Se vuelve difícil cuando vas a Francia y esperas que hablen americano y usen la misma moneda; aprende a hablar 10 palabras en francés, y te recibirán con los brazos abiertos, y tendrás una experiencia bastante diferente con los lugareños.

De todos modos, adelante con la implementación del modelo. Solo date cuenta de que probablemente haremos un cambio en algún momento. Guarde todo su DDL. Guarde todos sus datos de prueba como declaraciones de inserción o como copia de seguridad de tabla o exportación de formato de caracteres (no tengo idea de lo que MySQL puede/no puede hacer en esta área).
37.1. Manejada, la relación n::n con Office &Category . Solo "verás" eso cuando lleguemos al modelo físico.

37.2. Listo.

37.3 Listo.
.
38. Excelente. Más corto también. Tenga en cuenta que nunca podrán tener dos Offices en el mismo código postal. NUMERIC(5,0) es bueno, pero pensé que EE. UU. se estaba moviendo hacia los 7 dígitos. No importa, puedes resolverlo; es un PK excelente para Office . Ahora esta columna, que formaba parte de Address , probablemente ZipCode , ha sido elevado a un propósito superior, sin duplicación; dado que lo llevamos en 5 tablas secundarias y queremos que el nombre de PK sea claro, según las convenciones explicadas anteriormente, lo llamaremos OfficeCode; OfficeZipCode podría ser una tontería.

Necesitamos un índice único en Name para asegurarse de que no agreguen dos Offices con el mismo nombre. Tenga en cuenta que, con fines explicativos, esta es en realidad la clave lógica de Office , reemplazando (StateCode, Town) , y sigue siendo así.

Sigo pensando que puede necesitar StateCode y Town como una referencia rápida (aparte de sentarse en algún lugar en Address )

Modelo de datos actualizado, Fifth ahora disponible para revisión. No indicó su preferencia, por ...Date vs ...Dtm . Me quedo con este último, ya que es más específico, identificando también el componente de tiempo. Fácil de cambiar.

Esta respuesta ha alcanzado la longitud máxima. Continúa en la "Parte II"