Design and Architecture Discussion Boards

If you are expecting to make a decent amount of money out of this, then creating a company is probably a good idea. If you can't, have you considered selling your app through the Intel AppUp Store[^]? That allows you to sell as an individual.

*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier

Living in Greece it is a drawn back for creating a company Frown | :(

Do you think that intel AppUp will accept desktop application? This is interesting, I'll check it when I get back home.

First BASIC, then q-BASIC, moved to Pascal and Delphi, studied and work on C++, moved to C# and (unfortunately VB), learned JavaScript and after all these languages learned... when I travel abroad I have to speak English.
browse-offline.com

Menelaos Vergis wrote:
Do you think that intel AppUp will accept desktop application?

They most certainly do.

*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier

Hello, CP. So I am working on this application here at work and the current piece involves inventory management. First, I will list the tools I use:

Visual Studio 2010 Ultimate
C#, .NET 4.0
Microsoft SQL Server 2008 Enterprise
LINQ To SQL

Now, what I have are various types of items which need to be tracked. They are referred to as "RPCs" (and they are all computer parts). I have been thinking on this for a while but I need to figure out the most efficient way (both from a development standpoint as well as from an end-user standpoint) to input data and store these items in the database.

What I have done so far, for the first three types of RPCs, is I have created a UserControl. On that control are the fields necessary for that particular RPC type. Each RPC has various attributes which are not shared among other types. For example, a Hard Drive has Marketed Size, Physical Size (2.5" or 3.5"), RPM while a CPU has Clock Speed, Cache Size, # of Cores. I think you get the idea.

Well, I started out with these three UserControls as well as three tables in the database, one for each type. However, the issue really becomes known when I say this: to start with, I have roughly 25 diferent RPC types.

So is there a way I can keep from creating 25 UserControls, one for each type? Or 25 tables in the database just for RPCs? I thought about creating a single table with the specs that each type does have in common (e.g. Manufacturer, Model) an storing the specs in a specific format (e.g. XML) in a column and having the application manipulate the specs data as necessary. However, the performance issue arises when I think about the fact that I must be able to search various RPC types by one or more specs. For example, the application needs to be capable of finding all 500GB/7200RPM hard drives. That wouldn't work so well when using XML for all of the specs would it?

Maybe I am going about this whole thing all wrong. But then again, maybe I am better off going with the numerous tables and user controls. If that's what it takes, I'll do it. I just started thinking about it early on and realized that maybe I am not being entirely efficient with it.

Any suggestions? Big Grin | :-D

djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.

Matt U. wrote:
but I need to figure out the most efficient way (both from a development
standpoint as well as from an end-user standpoint)

Then you really need to have some more requirements.

For example will 100,000 users access this?
Will there be 100 billion of these?
Will there be 1000 retail locations attempting to access it?

Questions like that impact the design.

Matt U. wrote:
So is there a way I can keep from creating 25 UserControls, one for each type?

Yes.

Is it ideal in terms of your actual business requirments? I have no idea.

But the idea is simple you have a inventory item with "properties". In the simplist scenarios there business needs for the properties are very simple so consequently one can store them in a property table.

That table would look like this

Property (primary key id is assumed)
- inventory_id
- name
- type
- value

That table would have a row like the following
<some inventory="" id="">, "Clock Speed", "Decimal", "2.66"

There are many variations on the above. For example instead of "Clock Speed/"Decimal" you could have an enumeration table that define a 'type' and then the property id would tie to that type via the type id.

First of all, thank you for the response.

jschell wrote:
For example will 100,000 users access this?

Will there be 100 billion of these?

Will there be 1000 retail locations attempting to access it?

There will only be a handful of people who access this portion of the system.

There will only be roughly 25 item types. However, there may be several variations of each item type. (500GB 5400RPM, 500GB 7200RPM, 750GB 5400RPM, etc.)

There is only one facility which will access this application. It's all in-house/local.

jschell wrote:
But the idea is simple you have a inventory item with "properties". In the simplist scenarios there business needs for the properties are very simple so consequently one can store them in a property table.

So if I were to implement this idea would I have the following?

Inventory Table
------------------------
- InventoryId
- Manufacturer
- PartNumber
- ItemType
- TotalQty (this is the total qty. of this item in inventory)
- AvailableQty (this is the qty. (must be <= TotalQty) of this item which are available for picking)

Properties Table
------------------------
- InventoryId (linked to Inventory Table)
- Name
- Type
- Value

Am I understanding it correctly? Also, as far as not having that many UserControls, how could I reduce that number? I'm still thinking on that one and trying to figure it out. Smile | :)

djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.

Matt U. wrote:
Am I understanding it correctly?

Yes.

However why are the other fields not properties as well - like 'part number'?

Quantities are probably functional so those wouldn't be properties.

Well, I figured since the 'Manufacturer' and 'Part Number' fields were common among all items, why not have those fields in the base table. Would there be any real advantages of placing them in the Properties table? Or is it more for separation of purpose?

djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.

Purpose not commonality is what drives the design.

Part number might be broken out because you need to drive functionality from it - like queries and/or B2B work. I doubt Manufacturer woujld have that same need.

However it is still somewhate subjective especially since your volume is low. You might just keep them there to make it easier for the DBA to investigate stuff.

I understand, that makes sense. Oh, it will make it easier for me to investigate stuff? LoL. I run the entire show when it comes to designing and developing software here. I design the databases, maintain the servers, write the software, etc. Haha. But I understand your point. Thanks a lot for all of your input.

djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.

In one company I worked at, we coded these characteristics into the .part number itself.

For instancr, a 4000 series graphics chip could have a speed rating of 24, 32 or 40 MHz.

It would be numbered as 4000-24, 4000-32 and 4000-40.

In the case of your CPU, the part number could be i3-1.4-c2-v2 for Intel i3, 1-4 GHz, 2-core, version 2 model.

In this case, one needs to only have the part number entered correctly into the system and not have to worry about some Tom, Dick or Harry entering all the characteristics in a separate property sheet.

Your disk drive could be numbered DISK-2.5-500-7200 for a 2.5", 500GB, 7200 RPM drive. You can even add SATA, PATA by using an S or a P at the end.

Don't know if this would meet your needs or not.

I had already taken that into consideration. However, the part numbers come from corporate. We have no control of them whatsoever so we're a bit limited in that aspect. :-/ I figured it out though, using the separate table as mentioned.

djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.

We used to supply parts to the Itty Bitty Mitty Computer Corporation who wanted to see only their part number on the chips as well as on the shipping documents.

Our Inventory Control system allowed for alternate part numbers so the user could put in their part numbers and the system would still point to the one that we used inside our company.

Oh, interesting. Well, our current implementation seems to fit our needs. But I'll keep this idea in mind. Thank you, Vivic.

djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.

Is it recommended to use microsoft enterprise library for heavy traffic sites ?

If not please suggest some architecture.

Sandeep Bhatti wrote:
Is it recommended to use microsoft enterprise library for heavy traffic sites ?

It is efficient code, and unless one would like to implement their own logging-mechanism, test it, and maintain it, entlib is the recommended way. Same goes for caching, data access and exception-handling.

Sandeep Bhatti wrote:
If not please suggest some architecture.

EntLib is not an architecture. What you'd probably be looking for is the MVC-pattern, which is also not an architecture.

Bastard Programmer from Hell Suspicious | :suss:

if you can't read my code, try converting it here[^]

Deleted

Nothing is true and everything is permitted!

modified 24-Oct-12 8:07am.

1. It is considered bad form to ask for reviews of your article. Articles will get reviewed by CodeProject members in their own time.
2. If your application is going to win a prize in the contest then it needs to be all your own work.

One of these days I'm going to think of a really clever signature.

Saif Al Falah wrote:
P.S. You could also rate and comment on my article. That would really help a lot.

That looks to me like asking for a review.

If other people suggest extra features for your app then it is not all your own work. The competition is about innovation, so it is not just coding a solution but coming up with the ideas and design in the first place.

One of these days I'm going to think of a really clever signature.

I was afraid to post this under a general discussion forum, and it looks like this might be the closest fit ... so here goes.

For a couple of years now, I have received unwanted calls from Online Pharmacies to Debt Reduction Services, and I am so tired of telling them I am not interested and/or to remove my name from their list. Cell phone service carriers are useless, for the most part, and usually one has to resort to just blocking the offending call. But, needless to say, the offending callers will just change their number to another one, and the cycle starts over again.

Researching these numbers on the internet usually turns up a list of others complaining about the exact same phone numbers. So, it is not just me. The latest number, (617) 371-4000, appears to be someone spoofing a legitimate investment company, which is sad for the company that actually does own that phone number. There has to be something better I can do to resolve this ... I am a programmer, I am a technician, and I am (reasonably) smart!

I am not a mobile device programmer, though I feel certain that I might be able to bulldoze my way through building an app - though it wouldn't look pretty, and there would be some serious doubt about the functionality of it. So, I am looking to you (the development community) to help create a solution. I am ok with someone else profiting from the ideas I am about to propose, my reward will be in having these calls stopped, and that IS priceless.

I believe that a simple app (Android, iOS, and/or even Windows) which maintains a list of offending phone numbers and when a phone number is matched to an inbound caller, instead of alerting the user that a phone call is coming in ... answer the call ... but act like a fax machine. The app should act completely like a fax machine, even to the point of accepting a fax transmission if it provided ... just don't do anything with the incoming data. It might even be possible to give the user an extra button for incoming calls ... The normal choices for incoming calls are Answer and Decline, maybe the application can add a third option ... "FAX Spoof"

The people responsible for these spoofing efforts (and I do understand that it might be multiple groups of multiple individuals, and might not even be connected or aware of each other), do not care what you do or say ... They just move on to other numbers, and if necessary move their numbers as well. Cursing at them doesn't work. Phone carriers are useless. I truly believe that the only way to stop it is to eventually have MY number show up in their list as a useless fax number, and I believe a tool like this would work wonders at bring that situation about.

Unwanted calls fall into one of the following
1. Outright fraudulent.
2. Unintentionally fraudulent.
3. Legitimate but abusive.
4. Legitimate but useful.

The first will change telephone numbers often.
2/3 will seldom change numbers but there is a lot of them.
4 you want to get them.

Black listed numbers won't help for 1.
Black listing for 2/3 won't help unless one number repeatedly calls.
Obviously you wouldn't want to black list 4.

White listing won't help if you want 4.

pdelayCA wrote:
Cursing at them doesn't work. Phone carriers are useless.

In the US there are various ways to deal with this. You put your number on do not call lists. You can file written complaints. You can sue at least in some jurisdictions. A least in some cases it is small claims court which telemarketers would be loath to fight since it is local to the consumer not the telemarketer.

http://www.npr.org/templates/story/story.php?storyId=7532224[^]

pdelayCA wrote:
<layer>I am not a mobile device programmer, though I feel certain that I might be able to bulldoze my way through building an app - though it wouldn't look pretty, and there would be some serious doubt about the functionality of it. So, I am looking to you (the development community) to help create a solution.

They already exist.

My colleagues and I have been maintaining an old client/server application for years and we want/need to utilize new technologies (new compared to the framework 2.0-type stuff we've been doing) to make using/maintaining our application much easier.

The current application is setup as follows:
1) This is a legacy windows desktop application
2) We have thousands of customer companies. Each company can have 1 or more locations. Each location can have 1 instance running per machine, but multiple instances (running on separate machines) can access the data of that location at any time.
3) We have a client database on every computer that stores a copy of the server data (this is to make reads faster). Whenever data is inserted/changed/deleted the operation is performed server-side, then local db is synched with the server db (we use timestamp comparisons to check for consistency). We also check timestamps before CRUD operations to makesure the local data is up-to-date (since other computers could be working with the same data server-side).
4) Our largest tables have ~300k rows per location

I've really been interested in the Entity Framework in conjunction with WCF Data Services and I have a couple of questions about how the new app (v2.0) should be setup.

Questions:
1) Should we abandon the use of a local DB? Our customers are required to have a broadband connection, so speed wouldn't be a huge issue, I am concerned though about bandwidth usage.
2) If we should keep the local DB, does WCF support this type of data model? I haven't been able to find any examples of people doing this (which is leading me to believe it's a bad idea)
3) Are there other alternatives to the Entity framework and WCF that would better suit our applications needs?

Just a side note, none of the developers currently working on the software were employed here when the current architecture was developed.

EDIT: I forgot to mention another aspect of our current setup: Each company can have location data on a number of different databases. Each location's data is only on 1 database.

modified 17-Oct-12 18:10pm.

It seems that no-one is willing to answer you, so I'll give it a shot.

sephus6 wrote:
1) Should we abandon the use of a local DB? Our customers are required to have a broadband connection, so speed wouldn't be a huge issue, I am concerned though about bandwidth usage.

Depends, mostly on the size of the recordsets you fetch. If it's limited to getting the data that's going to be displayed, then broadband is broad enough. If you're going to perform lots of manipulations on the data while moving back and forth, it might be more performant if you could do it locally.

You might want to consider a hybrid; keep the data 'in the cloud' (on your server), and have tables that aren't mutated in a local database. Or synchronize the most used data to a local cache - most reports don't require 'realtime' data, and are quite happy with a database that's synchronized every now and then.

sephus6 wrote:
2) If we should keep the local DB, does WCF support this type of data model? I haven't been able to find any examples of people doing this (which is leading me to believe it's a bad idea)

All the "local" examples would treat the server as if it's "remote"; that's due to using WCF - communication. Without WCF, you'd be talking directly to the local database. That might be an option too; it's faster, but makes it harder to share data. I'd recommend it only for the reports, who could use a local (readonly version) of the data.

sephus6 wrote:
3) Are there other alternatives to the Entity framework and WCF that would better suit our applications needs?

An alternative to EF would be NHibernate, but EF is a bit more than just an ORM. I think the tools you choose are the best for the job; with the added suggestion to add EntLib in the mix of ingredients.

Bastard Programmer from Hell Suspicious | :suss:

if you can't read my code, try converting it here[^]

sephus6 wrote:
to make using/maintaining our application much easier.

I doubt that will happen.

Since you already have experience with the existing application you know how it works. To re-write it you would need to learn one or more technologies and correctly implement them. Even supposing that if everything was equal while you were learning and correctly implementing the new stuff it would in fact be harder to maintain the application.

If and only if you do everything correctly then in time it might be easier. I doubt however that it would be "much" easier. Although if the original application did not grow in a disciplined way and the new application does then it could be. That however has nothing to do with technology.

sephus6 wrote:
3) We have a client database on every computer that stores a copy of the server
data (this is to make reads faster).

Based on the rest of your post the real reason for this concern was probably network latency. Older databases didn't have problems with read speed.

sephus6 wrote:
I am concerned though about bandwidth usage.

That depends on application usage. Exactly what do your users do for their normal work flow. You can't answer the question without that knowledge nor can you really architect a solution without that either.

sephus6 wrote:
If we should keep the local DB, does WCF support this type of data model?

If your user base is really using different databases (which is different than a marketing claim that someone could if they wanted to), then you would need to craft a solution to do this yourself. Your current architected solution is still sufficient in that regard.

WCF doesn't provide anything specifically helpful for that.

sephus6 wrote:
Are there other alternatives to the Entity framework and WCF that would better
suit our applications needs?

I doubt that can be answered without more specific information. At a minimum it can't be answered without at least some specific information about what exact traffic you anticipate. A medical imaging system is vastly different than a cash register app.

sephus6 wrote:
Each company can have location data on a number of different databases. Each
location's data is only on 1 database.

Not exactly sure what that means. I also question if your customers, at least a significant number, actually do that.

If your customers really do do that or if you really want to continue to market it that way (despite no one doing it) then it rules out database replication which would normally be the way to do this.

Hi all,
I have taken ownership of a Sql 2008 database that has a huge number of rows with HTML content. I need to implement some new functionality that would let users intelligently search through within the HTML of these records.

Any suggestions?

thanks,
Saurabh

saurabh