.net - paso - como hacer una base de datos en html y php
Primero en el código o en la base de datos, ¿cómo elegir? (11)
Modelado de dominio vs modelado relacional
Hay varias formas fundamentales de cómo podemos expresar nuestras ideas de dominio empresarial
Creo que es importante establecer primero que el dominio es independiente de las tecnologías concretas y / o paradigmas de programación (por ejemplo, OO, FP, relacional). Esta respuesta supondrá que ya ha definido por separado su dominio, por ejemplo, utilizando prácticas DDD, y ahora desea utilizar una base de datos relacional para almacenarlo.
Fortalezas del modelo relacional
El modelo relacional se inventó, entre otras razones, para eliminar los muchos problemas causados por modelos anteriores, incluido el modelo en red (que incluye modelos OO), el modelo jerárquico (que incluye modelos XML / JSON) o la clave simple tiendas de valores. Tiene muchas fortalezas sobre todas las alternativas, lo que la ha hecho tan popular durante décadas.
En mi opinión, estas fortalezas indican que debe diseñar su modelo de base de datos dentro de la base de datos, que se ha realizado precisamente para ese propósito. Todos los demás modelos, incluido su modelo de cliente, son copias de ese modelo relacional original desde la base de datos. Por lo tanto, todos los otros modelos deberían derivarse de él, no como fuente para él.
Vea el modelo relacional, expresado en DDL, como su fuente de verdad
XSD es lo mismo
XML / XSD es una tecnología similar. Sus datos se expresan en términos de XML, pero cuando dos sistemas se comunican entre sí a través de una API basada en XML, XSD (o, por ejemplo, WSDL si lo desea) es el lenguaje más apropiado para especificar esa comunicación.
Si desea enlazar sus documentos XML usando la tecnología del cliente, por ejemplo JAXB en Java, entonces debe generar esas clases JAXB del XSD, y no al revés. ¿Por qué? Porque XSD es la fuente de la verdad
Supongamos que vamos a iniciar un nuevo proyecto, una aplicación que contiene cierta lógica comercial, interfaz de usuario en ASP.NET, WPF o ambas. Nos gustaría utilizar el generador de código ORM o DAL e implementar nuestra lógica comercial en clases .NET. Hay varias formas fundamentales de cómo podemos expresar nuestras ideas de dominio empresarial:
- Implementar clases de negocios en .NET y dejar que ORM genere el esquema de base de datos apropiado
- Crear esquema de base de datos de forma manual y generar clases .NET por generador de código
- Utilice algún tipo de diseñador visual, que pueda generar clases de negocio y estructura de base de datos o script
¿Qué prefieres escribir: "Crear personas de la tabla (...)" o "Persona de la clase pública {...}"?
¿Cuáles son los pros y los contras de esas formas?
Tal vez hay algunas situaciones especiales donde una forma es mejor que otra?
¿Cómo elegir la forma óptima en un proyecto en particular?
Estoy bastante familiarizado con el modo "Code-First" (o "Model-First"), pero parece que la mayoría de los ORM están diseñados como generadores de código o mapeadores, que suponen que implementaré manualmente tanto la estructura de la base de datos como las clases de negocios.
Las respuestas basadas en expirience y ejemplos de ORM son especialmente bienvenidas.
Editar: Tenga en cuenta que la pregunta no es "¿Qué debo hacer primero al iniciar un nuevo proyecto?", Sino "¿Qué debería declararse / generar automáticamente, las clases de dominio o la estructura de la base de datos?"
"Muéstreme sus diagramas de flujo y oculte sus tablas, y continuaré desconcertado. Muéstrame tus tablas, y normalmente no necesitaré tus diagramas de flujo; serán obvios ".
- Fred Brooks en "The Mythical Man-Month"
¿Por qué no interfaz primero?
Demasiadas aplicaciones comienzan con una mentalidad de primer programa. Esa es una mala idea La programación es el componente más pesado de la creación de una aplicación, lo que significa que es la más costosa y la más difícil de cambiar. En cambio, comience diseñando primero.
El diseño es relativamente ligero. Un boceto en papel es barato y fácil de cambiar. Los diseños html son relativamente simples de modificar (o descartar). Eso no es verdad de la programación. Diseñar primero te mantiene flexible. La programación primero te acerca y te prepara para costos adicionales.
Esto es del Capítulo 9 de Getting Real by 37signals.
Comience por no pensar directamente en cualquiera de los dos, sino en "modelo" (preferiblemente en papel) de las partes que tendrá su aplicación desde el punto de vista de los usuarios.
Si tiene una imagen mental clara de ese modelo, puede dividir las partes en pequeños elementos comunes y específicos que puede traducir tanto a definiciones de objetos como a tablas de bases de datos.
Encuentro que este método reduce significativamente el tiempo y el esfuerzo de normalización de la base de datos.
En la mayoría de los casos, no importará mucho. Es más de preferencia personal y habilidad que cualquier otra cosa. La mayoría de las aplicaciones no van a sufrir mucho, use lo que sea que su equipo se sienta cómodo. Donde la opción realmente importa, debería ser obvio qué enfoque elegir.
Dicho esto, mi opinión personal es que "la base de datos primero" es generalmente la opción más segura. Si los datos son de alguna manera importantes, especialmente si son importantes fuera del alcance de su aplicación particular, quiere tener un control total sobre cómo se almacenan.
"Código primero" (implícito: dejar la base de datos en manos de alguna herramienta automática) es en mi mente realmente un acceso directo, uno que debe usar cuando (y solo cuando) sepa con certeza que puede salirse con la suya.
En mi opinión, no hay una respuesta correcta para esto. Supongo que en su mayoría se reduce a sus preferencias personales o de sus equipos. Todos los enfoques mencionados (primero la base de datos, primero el código, la interfaz primero) tienen sus propias ventajas y desventajas.
Probablemente me siento con lápiz y papel y bosquejo la estructura general y las funciones principales de la aplicación antes de hacer algo específico, ya sea el código o las tablas de la base de datos. Un simple dibujo de la interfaz de usuario básica también ayuda mucho.
Hay tres aspectos importantes que deben tenerse en cuenta al desarrollar una aplicación de base de datos ...
- Experiencia de usuario
- Calidad de datos
- Costo para mantener los dos primeros (Experiencia del usuario y calidad de los datos)
Creo que la prioridad de estos tres elementos se expresa en el orden en que se presentan, lo que significa que la mayor prioridad es la experiencia del usuario, la segunda prioridad es la calidad de los datos, y el tercero es el costo para hacerlo. Por supuesto, esto puede debatirse, pero la noción de código primero o base de datos es en primer lugar relativa a la tercera prioridad: el costo. Cualquiera que sea la elección, codifique primero o la base de datos primero, asegúrese de que se cumplan las dos primeras prioridades ...
Para responder a su pregunta editada (manual db / auto classes o manual classes / db), elegiría "ninguno". El código autogenerado de ambos tipos debe evitarse por varias razones, en primer lugar, YAGNI. Terminas con un código que nunca escribiste pero que sin embargo es responsable, código que nunca utilizarás y (en mi experiencia) código terminarás gastando más tiempo refactorizando que si lo hubieras diseñado y escrito tú mismo en el primer lugar. Y ambos mantienen su enfoque lejos de la ubicación más importante: el usuario.
Personalmente, me gusta el control sobre la creación de objetos RDBMS. Cuando uso el código EF primero, realmente crea más trabajo para cosas básicas como relaciones de tabla, etc. que la mayoría de los generadores de códigos decentes hacen para ti de la caja (sé que esa es la idea ... ¡más control en tus Modelos!) . También la idea de que EFCF genere el DB como estoy esperando es un poco aterradora. (¡tradicionalmente el código evoluciona más fácilmente que RDMBS!)
Para un sistema que requería una evolución constante (por ejemplo, SaaS), y generalmente un gran sistema de Nivel Empresarial con más de 500 tablas, etc., puede ser una propuesta menos atractiva. Por otro lado, si tiene un proyecto de base de datos de SQL Server 2008 adecuado con todas las tablas, SP, Triggers, Indexed scripted y puede implementarlos desde Visual Studio, es mucho más manejable. Ahora tiene libertad de usar cualquier codegen que desee para sus tablas (incluso construya las suyas propias)
No estás vinculado al Framework on (EFCF), puedes usar diferentes ORM (NHibernet por ejemplo) dependiendo de tu ''mini'' requisito de proyecto en tu gran sistema.
Primero, el análisis de los requisitos y, a continuación, cierta documentación de esas necesidades y una visión general de los aspectos de datos de esto.
Entonces sabrá qué datos capturará y cómo se relaciona con otros datos, y puede diseñar un esquema de base de datos o estructura de datos para que coincida (como objetos lógicos / tablas de contenido relacionado, no "tab1_data", "tab2_data" que coincida con proceso de captura de datos que podría cambiar, pero usted lo sabe!). Incluso podría diseñar un .xsd primero y generar un código y un esquema de base de datos a partir de eso. En estos días, todo es diversión y juegos, según tu conjunto de habilidades.
Como el esquema de la base de datos en mi mente almacena los datos, y eso es lo realmente importante para una empresa, lo diseñaría primero: varias herramientas podrían acceder a él a tiempo, tal vez el sistema original sería reemplazado por la línea (ej. , migración a herramientas / idiomas / interfaces más nuevos). Si no sabe nada sobre la teoría de la base de datos, tal vez esa no sea su mejor opción, pero igual obtendría un esquema generado verificado por otra persona.
Creo que el enfoque apropiado para el análisis y diseño del sistema es comenzar modelando sus objetos y las relaciones entre ellos primero. Si está creando un sistema de biblioteca, debería pensar en las frases Libro, Autor, Editor, ISBN como objetos, no como tablas de base de datos o atributos. Creo que esta es la forma en que debería ser. Dicho esto, admitamos que los generadores de código ahorran mucho tiempo y requieren una base de datos relacional para generar el modelo y asignarlo a los objetos DB. Creo que esta es la principal razón por la cual los desarrolladores tienden a comenzar por la DB. Lo que podría probar mi punto más es que los desarrolladores de generadores de código están tratando de revertir la operación implementada actualmente (es decir, usted proporciona un modelo comercial -objetos y clases- y el generador crea la base de datos con el esquema apropiado para esto).
Editar:
Aquí hay un ejemplo de generadores de primer dominio (ADO.NET Entity Framework en sí) Modelo Primero :
Visual Studio 2010 tiene capacidad para generar un DDL y crear una base de datos para almacenar el modelo de datos de la entidad. El desarrollador tiene control total sobre el proceso completo, pudiendo personalizar el DDL, o seleccionar la base de datos que desee, o ajustar el proceso de mapeo.