I have a Lightswitch project written in C# with Silverlight. I've been thinking and looking for a professionnal way to deal with single entities/objects that must be modifiable by users, and having those changes be reflected for every other user. Those entities don't belong to any table because they don't share similar fields, and obviously I wouldn't want to create a table for each one of them (about 10-20).
An example would be a multiplying factor for some specific pricing. That factor must be the same for every user, but the users must be able to change it after some time because pricing structure changes.
What would be an efficient way to deal with those ?
More info on the project:
Users will want to be able to go to a specific screen, change the value of the entity in a textbox for example (could be any other UI element though), and then some other entities would use that new value for their computed properties.
Related
I am making a 3-layered architecture database application with C# Windows Form application and an Excel file. Problem is, I have three tables and they have different amount of attributes. I want to user chooses which table he/she want to insert and update.
The basic solution is making three different forms to add values to each table, because for different amount of inputs I need different amount of textboxes. But it's too troublesome and amateurish, I think.
Can you give me some advise to do this easily?
Something that you could try is using a DataGridView.
A drop-down could be used to determine what table the user would like to modify. Based on this input, query your database and bind the results with the DataGridView.
A reference you could start with "https://learn.microsoft.com/en-us/dotnet/framework/winforms/controls/data-entry-in-the-windows-forms-datagridview-control"
Simpler method will be a big table with all the fields. Allow null on the ones you will allow user to skip.
OR
Create a table with bare minimum fields a user must enter. Create other tables and connect them using a foreign key constraint. On the front end, allow the users to leave fields empty. You should be done.
I Want to let user decide which column or field he want's to add in Objectand depending on what data type he has chosen to create that field, user should able to make CRUD operation on that object with data type chosen by him to create that custom field. Is it possible or not, If yes what are the optimum ways to create it? (All this operations to be made in browser and not from code)
You cannot "dynamically" add a column to a table per row. If the user could add a column, then that column would be added to the table in general, and every row in that table would have it. Even if this was possible, it would require granting your application admin rights on your database, which is a huge security faux pas. The database user exposed to the web should have only the most minimal privileges necessary: usually just INSERT, UPDATE, SELECT, and DELETE, and sometimes not even all of those. Anything more puts you at huge risk of SQL injection attacks and similar by malicious users. This is database 101 stuff, so it may behoove you to step back and learn more about the platform you're developing on before proceeding.
It's sounds like you're basically just want something similar to a "settings" table. The way these things normally work is store the name of the "setting" and a value for that as a string. You might also store a type value, also as a string. Then, after you retrieve the setting you can coerce the value into the proper type you need it as. That's really the best you can do with "dynamic" things, since a relational database is very much static. It needs to know the data and the types of that data it's going to handle in advance.
I have an application that I'm trying to store data in Amazon DynamoDB and I'm trying to figure out the best way to structure the tables. A quick description of the app:
It needs to be able to load a large number of elements from the DB based on a search of a small number of properties and display those limited properties to the user. Then the user can browse and select a few elements that they want to look closer at and it needs to show the rest of the properties for those items.
My thought is that basically for speed and memory purposes it needs to load a 'summarized' version of the objects for the initial step, then load the full object when the user asks to look into something fully. I can do this easily (and have done so) in my c# code. However here is what I'm wondering:
If I have a c# object and I use the Dynamo Object persistence SDK to relate say 5 properties to a Dynamo table that has say 30 properties; will the SDK request only the properties that are on the object? Or will it request all of them and then throw out the 25 that aren't related to the object?
If it only takes the needed properties then I think I can store everything in one table and relate both the summarized objects and the full objects to the same table and just pull the properties needed. If it takes everything then I'm worried it will create a lot of throughput that I don't need 75% of, plus slowing down the transfer due to the extra data. If that's the case I think it may be worth creating a GSI that just has the summarized properties...
Anyway sorry for the long description, any input from those more familiar with DynamoDB than I am would be appreciated :)
Assume that I have a entity data model I generated from my database. I use one of the columns throughout code in many places, but one day I decide that I don't need this anymore, so I remove it from the database and the places in code that reference this property from the entity data model are now broken. Is the only solution to this is to go to each place and fix it or are there any strategies or tools that can assist in scenarios like this?
This question is only practical for applications that haven't been released yet. If an application has been released and this column already exists, it would not be removed or deleted. Existing customers may be depending on that column for data, it may be tied to application logic etc. For compatability reasons, it wouldn't be removed.
If this is pre-production application (pre 1.0 release), any ORM solution should be able to recreate the logical and conceptable model(s) after the physical column in the database has been removed. At that point, there may be some cleanup in the other layers of the application (UI, business, etc) that reference conceptable model in some fashion. For example, the UI may need to be updated to remove the display of that data. That would require some manual effort.
In general, it is better to keep it unless the application is in the early stages of development.
As such, you haven't specified about data in column and need for removing it, so we have to talk in general terms.
If you can remove the column from database and yet has used it in many places at code then probably its computed column - In general, it means you can derive the same information from other data-points. So in your entity model, you should stop mapping the column to the database and rather replicate the logic in the code to compute meaning-full value for the property. Or you can create a view over the table and compute the column at database side and map your entity to the view instead of table.
In case, the column is not computed then removing the column from database means loss of data. And if that is acceptable then it essentially indicates the change in underlying business model where that data point become irrelevant. You have two choices here -
Go for it and change your code for not to use this property - it essentially means that you will adjusting your code for business model/process change that you have to eventually do at some time.
Keep the column in database for some time but have a meaning-full default value. Mark the entity model property obsolete so that it will start giving warning. Take your time to make code changes, ultimate aim is to remove the property usage over a time and then remove the database column.
I am having a little trouble deciding how to structure an application that I am building.
The application is required to parse through text-based files (one record per line) and load all of the information into memory. There are typically anywhere from 100,000 - 500,000 records. After that, the data must be displayed in the form of tables and very detailed graphs/charts for further analysis.
The user must have the ability to customize the view of this data. For example, there are many different "types" of log records (TypeA_Log, TypeB_Log, etc.) The user should have the ability to select/deselect these types, which will show/hide them from the display. There are several other types of filtering going on (filter by date, etc.)
--
Essentially what I have now is this:
I have a class structure that represents the various types of log records.
There is a Singleton pattern to hold all of the data (almost like a database in memory), which includes Lists<> of log record instances.
Then, I have a "filter" class which contains information about what the user would like to view. The "filter" gets passed into the Data-Singleton, and then returned a subset of the data. I am basically using C# lambda expressions to select data from a List<> of Log Records, similar to how you might pass in a SELECT statement to a SQL database.
--
This is working okay, but I have to think there is a better way of handling this. Right now, anytime the user makes even the smallest change (for example, selects/deselects one of the many types of log records, a new data set has to be retrieved from the Data-Singleton, and then all of the tables and charts have to be refreshed/rebinded/recomputed to reflect this change. All I really want to do, in most cases, is show/hide certain things.
I am using C# .NET 3.5.
You could build some sort of internal notification system, something also called event dispatcher.
Lets say have a record changed in one form, and instead of reloading other dependent forms, you fire the event that some record has changed (attach the record with some custom EventArgs), and let your dependent forms decide on event handling should they include this new record somewhere. You could update the changed data in the collections of the dependent forms.
However, this can create some concurrency problems (when you avoid rooundtrips to the database (text files in your case) )...