database-design

问题 So, I've read a lot about how stashing multiple values into one column is a bad idea and violates the first rule of data normalisation (which, surprisingly, is not "Do Not Talk About Data Normalisation") so I need some help. At the moment I'm designing an ASP .NET webpage for the place I work for. I want to display data on a web page depending on what Active Directory groups the person belongs to. The first way of doing this that comes to mind is to have a table with, essentially, a column

问题 I'm developing an Entity Framework Code First (v. 4.4.0.0) C# library with .Net Framework 4.0. I don't know how to set zero-to-one relationship. My model is the following: A Talk can be created by only one user ( StarterUserId ). A Talk can have only one recipient user ( RecepientUserId ) or only one group ( RecipientGroupId ). Note : That means that RecepientUserId is null if RecipientGroupId is not null; or RecepientUserId is not null if RecipientGroupId is null. A user can be a recipient

问题 I'm trying to understand a simple music database design. There are some tables that contain only foreign keys and a primary key. I'm not sure how and when to use these tables or what to insert into them. The design looks like this: Track: id primary key title duration live-performance (true or false) year Artist: id primary key name ArtistTrack: id primary key artistID trackID Album: id primary key title AlbumTrack: id primary key albumID trackID track-number Genre: id primary key name

问题 I've taken over development on a project that has a user table with over 30 columns. And the bad thing is that changes and additions to the columns keep happening. This isn't right. Should I push to have the extra fields moved into a second table as values and create a third table that stores those column names? user id email user_field id name user_value id user_field_id user_id value 回答1: Do not go the key / value route. SQL isn't designed to handle it and it'll make getting actual data out

问题 I have a really simple mediaTypes table which contains the following columns: id string name string Each mediaType record can have many "placements", which could easily be designed as follows: Placements id string mediaTypeId string (links to mediaTypes.id) name string detail_col_1 detail_col_2 ...etc However depending on the media type, a placement can contain different details, so if I designed the schema this way I may end up with a lot of nullable columns. To get around this, I could have

问题 I have a really simple mediaTypes table which contains the following columns: id string name string Each mediaType record can have many "placements", which could easily be designed as follows: Placements id string mediaTypeId string (links to mediaTypes.id) name string detail_col_1 detail_col_2 ...etc However depending on the media type, a placement can contain different details, so if I designed the schema this way I may end up with a lot of nullable columns. To get around this, I could have

问题 Why when I want to open design view of table in MySQL database It every time throws error I can view data, edit data, manage data but can't edit table definition. I use Visual Studio 2015 Community, MarriaDB 10.1.9 and MySQL for Visual Studio 1.2.6. 回答1: I was able to fix this problem by uninstalling Connector 6.9.9 and installing 6.9.8 - https://downloads.mysql.com/archives/c-net/ 回答2: You need to install the Dot Net Connector. http://dev.mysql.com/downloads/connector/net/ 回答3: It's 2018 now

问题 I understand it is possible to store images in Databases as Binary large objects. But I used to see in some forum web applications that they are stored as flat files in web server machine and retrieved when needed. What is the advantage and disadvantage in both methods? When to go for which approach? 回答1: As usual, it depends. You need to consider the usage pattern of the images and what features your DBMS provides. Storing images in the database: PROS If the images are to be associated with

问题 I understand it is possible to store images in Databases as Binary large objects. But I used to see in some forum web applications that they are stored as flat files in web server machine and retrieved when needed. What is the advantage and disadvantage in both methods? When to go for which approach? 回答1: As usual, it depends. You need to consider the usage pattern of the images and what features your DBMS provides. Storing images in the database: PROS If the images are to be associated with

问题 I am considering changing a database scheme to reduce the number of tables. I have several tables that contain different-yet-similar data, and am wondering if it is best practice to leave it this way, or if there would be complications with combining them. For example, let's say I have the following two tables: Table `status` `status_id` | `status_text` --------------------------- 1 | Open 2 | Closed 3 | On Hold Table `type` `type_id` | `type_text` --------------------------- 1 | Regular Work