![]() In the same vein, however, they should not be used as a substitute for knowing how the processes they employ actually work. LINQ to SQL is fantastic, just like graphing calculators are. You have, however, already crippled yourself in understanding SQL and the best practices that go along with it by immediately jumping into using an ORM. SQL is designed to store your sets for you, not to provide you with a "bucket" for you to store a set yourself. The last point is obviously the salient point here. Every row/column intersection must contain one and only one value.Any ordering of the data must be defined by the data, not by the physical ordering of the rows (SQL is based upon the idea of a set, meaning that the only ordering you should rely on is that which you explicitly define in your query).This also means that no row should be duplicated. You must be able to differentiate one row from any other row (in other words, you table must have something that can serve as a primary key.The Wikipedia article on database normalization is actually pretty good.īasically, the first rule (or form) of normalization states that your table must represent a relation. Normalization is designed to limit logical inconsistencies and corruption in your data, and there are a lot of levels to it. The principle you're violating is called first normal form, which is the first step in database normalization.Īt the risk of oversimplifying things, database normalization is the process of defining your database based upon what the data is, so that you can write sensible, consistent queries against it and be able to maintain it easily. Since you state that you're just learning SQL, I would strongly advise you to avoid this idea and stick with the practices recommended to you by more seasoned SQL developers. You're fighting an uphill battle and violating one of the most basic principles of relational database design for no good reason. I understand that you think it's silly to create another table to store that list, but this is exactly what relational databases do. There is no other way to do what you're talking about (because what you're talking about is a bad idea that should, in general, never be done). In order to store more than one value, you must serialize your list into a single value for storage, then deserialize it upon retrieval. Relational databases are designed specifically to store one value per row/column combination. No, there is no "better" way to store a sequence of items in a single column. I will allow the user to drag the nodes around to change the values occasionally or add more values to the plot. Rather, I will take all of them and plot them on the screen. (The table will also have other information that is of no consequence for our discussion.) I will never need to see part of the list of (x,y) pairs. Point me to some good references.Īlso, to give you a better idea of what I'm up to: In my database I have a Function table that will have a list of (x,y) pairs. So now I'm looking for explanations of why. UPDATE: So in the first flurry of answers I'm getting, I see "you can go the CSV/XML route. As soon as I had just begun understanding SQL and databases in general, I was turned on to LINQ to SQL, and so now I'm a little spoiled because I expect to deal with my programming object model without having to think about how the objects are queried or stored in the database. ![]() just a little more info to let you know where I'm coming from. Is there any better solution? If there is no better solution, then why? It seems that this problem should come up from time to time. But this also seems inconvenient because it means that I have to worry about serialization and deserialization. Finally, the list is basically atomic in that any time I wish to access the list, I will want to access the entire list rather than just a piece of it - so it seems silly to have to issue a database query to gather together pieces of the list.ĪKX's solution (linked above) is to serialize the list and store it in a binary column. Furthermore, the items in my list are explicitly sorted - which means that if I stored the elements in another table, I'd have to sort them every time I accessed them. However, the type of list I want to create will be composed of unique items (unlike the linked question's fruit example). Rather, you should create another table that effectively holds the elements of said list and then link to it directly or through a junction table. So, per Mehrdad's answer to a related question, I get it that a "proper" database table column doesn't store a list.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |