I want to add menu item from the database.
For example when I add a menu name into the database. It locates itself automatically.
Inside of the table, I have 3 columns.
ID, FormName, DisplayName.
How can I do it?
Thanks.
It isn't very clear what you mean, but: you can query the schema of tables either implicitly (select * from SomeTable, perhaps with a where 1=0, or there is a SET option to disable row returns) - then look at the IDataReader or DataTable or however else you're querying it to understand the layout; or perhaps better: by querying the meta-tables - INFORMATION_SCHEMA.COLUMNS etc. Once you know the column names and types, you can write a UI that does moderately suitable things based on that. If you need additional configuration, the "extended properties" feature of SQL Server allows you to store additional metadata against tables, columns, etc as name/value string pairs - essentially like [SomeAttribute(...)] in C#; for example, the MS_Description key/value pair is used by many UI tools to hold the descriptive label of a database entity (table, column, etc) - much like [Description("...")]. Putting all that together allows things to be barely tolerable by putting basic controls up to match each column/field with names and captions, but: a UI based on the raw database schema is usually very unsatisfying, and for most real work you'll want a custom UI with suitable logic and design considerations for the operation you're actually doing at the time.
Related
I have an ADO.NET DataSet that is persisted as XML. I need to add to it a list of cities and allow the user to select which city they're in. The selection has to be stored in the XML file along with the rest of the data.
This seems like a perfect use for DataSet.ExtendedProperties. However, it turns out that, in order for the extended properties to get written to the XML, I need to use XmlWriteMode.WriteSchema and XmlReadMode.ReadSchema, which adds the entire schema of the DataSet to the XML file just so it can add a single attribute, msprop:CityID.
My DataSet is strongly typed and its schema is hard-coded by the designer, so I really don't need to store the schema in the XML, which can lead to run-time errors.
So my question is, what's the best way to add the selected city to the DataSet itself. For example, using another table called SelectedCity, or using a Boolean column in the City table called IsSelected.
The SelectedCity table will always need to contain exactly one row, and the IsSelected column will need to contain true in exactly one row and false in all the others, and I don't know how to enforce such constraints in ADO.NET.
This seems like a fairly common scenario. What's the recommended way to code it?
If the relation is 1 to 1 put the field in the parent, but if a user can have various 1 to N put in another table. Sorry for my english.
Suppose i have one table that holds Blogs.
The schema looks like :
ID (int)| Title (varchar 50) | Value (longtext) | Images (longtext)| ....
In the field Images i store an XML Serialized List of images that are associated with the blog.
Should i use another table for this purpose?
Yes, you should put the images in another table. Having several values in the same field indicates denormalized data and makes it hard to work with the database.
As with all rules, there are exceptions where it makes sense to put XML with multiple values in one field in the database. The first rule is that:
The data should always read/written together. No need to read or update just one of the values.
If that is fulfilled, there can be a number of reasons to put the data together in one field:
Storage efficiency, if space has proved to be a problem.
Retrieval efficiency, if performance has proved to be a problem.
Schema flexilibity; where one XML field can eliminate tens or hundreds of different tables.
I would certainly use another table. If you use XML, what happens when you need to go through and update the references to all images? (Would you just rather do an Update blog_images Set ..., or parse through the XML for each row, make the update, then re-generate the updated XML for each?
Well, it is a bit "inner platform", but it will work. A separate table would allow better image querying, although on some RDBMS platforms this could also be achieved via an XML-type column and SQL/XML.
If this data only has to be opaque storage, then maybe. However, keep in mind you'll generally have to bring back the entire XML to the app-tier to do anything interesting with it (or: depending on platform, use SQL/XML, but I advise against this, as the DB isn't the place to do such processing in most cases).
My advice in all other cases: separate table.
That depends on whether you'd need to query on the actual image data itself. If you see a possible need to query on certain images, or images with certain attributes, then it would probably be best to store that image data in a different way.
Otherwise, leave it the way it is.
But remember, only include the fields in your SELECT when you need them.
Should i use another table for this purpose?
Not necessarily. You just have to ensure that you are not selecting the images field in your queries when you don't need it. But if you wanted to denormalize your schema you could use another table and when you need the images perform a join.
I have this problem and I don't know what is the best solution for it.
I have table called Employees and there is column called LastWork, this column should only have custom values I choose for example:
value 1
value 2
and I want the user to select the value from ComboBox control so I have 2 ideas for it but I don't know what is the best for it.
A - add these value to Combobox as string in Items property and store them as string in DB.
B - create separate table in my db called for example 'LastWork' with 2 columns 'LastWorkID', 'LastWorkName' and insert my values in it, and then I can add binding source control and I can use data bound items to store the id as integer in my main table and show the LastWorkName for users.
I prefer to use the B method because in some forms I have DataGridView control with edit permission, and I want to display Combobox in it instead of Textbox to select from these custom values.
I hope you understood my questions.
Normally data normalization is a good thing, so I too would go with your option B.
By having a separate table and a foreign key relationship to it, you can enforce data integrity; easily get a list of all available (not just all selected) options; have a single place in which to change the text of an option (what if someone decides to call it "value one" instead of "value 1", for example?); and so on and so forth.
These might not be huge benefits in a small application and with only two possible options, but we all know that applications very often tend to grow in scope over time.
In a normalized database, your "option B" is usually the way to go because it eliminates duplicate data. It will potentially introduce an additional join into your queries when you need the name (and not just the ID), but it also allows you to rename lookup names easily without altering their underlying IDs.
For performance reasons, it's often a good idea to cache lookup values such as you describe in the business tier so that your lookup table is not hit over and over again (such as when building many rows of a grid).
I would always save them in the db. If you have to localize your app, this helps alot. Additonally, it let you to apply the referential integrity checks of the database.
I want to allow the user to add columns to a table in the UI.
The UI: Columns Name:______ Columns Type: Number/String/Date
My Question is how to build the SQL tables and C# objects so the implementation will be efficient and scalable.
My thought is to build two SQL tables:
TBL 1 - ColumnsDefinition:
ColId, ColName, ColType[Text]
TBL 2 - ColumnsValues:
RowId, ColId, Value [Text]
I want the solution to be efficient in DB space,
and I want to allow the user to sort the dynamic columns.
I work on .NET 3.5 / SQL Server 2008.
Thanks.
I believe that is essentially how the WebParts.SqlPersonalizationProvider works, which doesn't necessarily mean it's the best, but does mean that after some smart people thought about it for a while, that's what they came up with.
Sorting on a given field will be a bit tricky, particularly if the field text need a non-text sorting (i.e., if you want "2" to come before "10").
I'd suggest that from C#, you do one query on ColumnsDefinition, and based on that, choose one of several different queries for selecting/sort the data.
Add a DefaultValue to your ColumnDefinition. Only add a value in ColumnsValues if the value is not the default value. This will speed up things a lot.
The thing I hate about these kind of systems is that it is very difficult to transfer changes betwween dev/stage/production because you will have to keep structure and content of tables in sync.
I'm creating a data-entry application where users are allowed to create the entry schema.
My first version of this just created a single table per entry schema with each entry spanning a single or multiple columns (for complex types) with the appropriate data type. This allowed for "fast" querying (on small datasets as I didn't index all columns) and simple synchronization where the data-entry was distributed on several databases.
I'm not quite happy with this solution though; the only positive thing is the simplicity...
I can only store a fixed number of columns. I need to create indexes on all columns. I need to recreate the table on schema changes.
Some of my key design criterias are:
Very fast querying (Using a simple domain specific query language)
Writes doesn't have to be fast
Many concurrent users
Schemas will change often
Schemas might contain many thousand columns
The data-entries might be distributed and needs syncronization.
Preferable MySQL and SQLite - Databases like DB2 and Oracle is out of the question.
Using .Net/Mono
I've been thinking of a couple of possible designs, but none of them seems like a good choice.
Solution 1: Union like table containing a Type column and one nullable column per type.
This avoids joins, but will definitly use a lot of space.
Solution 2: Key/value store. All values are stored as string and converted when needed.
Also use a lot of space, and of course, I hate having to convert everything to string.
Solution 3: Use an xml database or store values as xml.
Without any experience I would think this is quite slow (at least for the relational model unless there is some very good xpath support).
I also would like to avoid an xml database as other parts of the application fits better as a relational model, and being able to join the data is helpful.
I cannot help to think that someone has solved (some of) this already, but I'm unable to find anything. Not quite sure what to search for either...
I know market research is doing something like this for their questionnaires, but there are few open source implementations, and the ones I've found doesn't quite fit the bill.
PSPP has much of the logic I'm thinking of; primitive column types, many columns, many rows, fast querying and merging. Too bad it doesn't work against a database.. And of course... I don't need 99% of the provided functionality, but a lot of stuff not included.
I'm not sure this is the right place to ask such a design related question, but I hope someone here has some tips, know of any existing work, or can point me to a better place to ask such a question.
Thanks in advance!
Have you already considered the most trivial solution: having one table for each of your datatypes and storing the schema of your dataset in the database as well. Most simple solution:
DATASET Table (Virtual "table")
ID - primary key
Name - Name for the dataset/table
COLUMNSCHEMA Table (specifies the columns for one "dataset")
DATASETID - int (reference to Dataset-table)
COLID - smallint (unique # of the column)
Name - varchar
DataType - ("varchar", "int", whatever)
Row Table
DATASETID
ID - Unique id for the "row"
ColumnData Table (one for each datatype)
ROWID - int (reference to Row-table)
COLID - smallint
DATA - (varchar/int/whatever)
To query a dataset (a virtual table), you must then dynamically construct a SQL statement using the schema information in COLUMNSCHEMA table.