BV Commerce Forum
»
BV Commerce Community
»
Feedback & Suggestions
»
Revise stored procedures to use select ALIAS.* where possible
Rank: Member
Joined: 9/19/2010(UTC)
Posts: 104
|
Hi there, I'm making some customizations to the affiliates module to support "referred by affiliate x". In doing some I'm revising the BVSoftware.Bvc5.Core.Contacts.Affiliate.vb to include a new property that maps to a new database column. What winds up happening then is that there are many SQL dependencies to revise. There are a lot of stored procs just to filter and return affiliate rows. Those procedures specifically select individual columns. It would be nice if instead of selecting individual columns, those procedures could select <tableName>.*, i.e. bvc_Affiliate.* instead. That would reduce the number of dependencies that would have to be accommodated for when making changes such as these. Unless there are design reasons for specifically selecting certain columns, or perhaps performance reasons that I'm unaware of. Thanks! |
Best regards, Shan Plourde www.pahsah.com+1 (416) 628-1280 -------------------------------- |
|
|
|
|
|
Rank: Member
Joined: 11/5/2003(UTC)
Posts: 1,786
|
It's pretty common to not use SELECT *. One reason is that you are not specifying which columns to return and if a developer or DBA adds a bunch of new large columns it could affect the application without you knowing it. The second reason is for security purposes. Explicitly specifying column names reduces the surface exposure should you want to leave out certain columns.
Now, in reality, most of the stored procedures for select pull back all the columns. I know it can be a lot of work to modify the stored procedures when adding columns and that's one of the reasons we've started using ORM mappers like LINQ 2 SQL.
We are seriously investigating Entity Framework 4 as well as other NoSQL options for object->storage mapping in the future which will help speed up this kind of development.
|
|
|
|
|
|
Rank: Member
Joined: 9/19/2010(UTC)
Posts: 104
|
Thanks, good idea to use an ORM which would definitely reduce these types of changes. And considering your business layer is already an object based API versus DataRows it is a good natural progression. Fluent nHibernate is a pretty mature ORM framework.
Is the NoSQL thing for pure object databases? |
Best regards, Shan Plourde www.pahsah.com+1 (416) 628-1280 -------------------------------- |
|
|
|
|
|
Rank: Member
Joined: 11/5/2003(UTC)
Posts: 1,786
|
NoSql databases store "documents" which can be objects but are primarily graphs of key/value pairs. There are a lot of issues to "discover" with NoSql so an ORM is probably a first step in that direction.
|
|
|
|
|
|
Rank: Member
Joined: 11/25/2003(UTC)
Posts: 370
|
Shan, different tools for different purposes. Here is a short overview of NoSql which is not such a great tool for our business e-commerce applications. http://www.sqlmag.com/article/d...pment/NoSQL-No-Way-.aspx |
|
|
|
|
|
|
Rank: Member
Joined: 9/19/2010(UTC)
Posts: 104
|
Thanks Kim, I found a good resource at Stack Overflow as well on the definition of NoSql, http://stackoverflow.com...enefits-does-it-provide.As far as the massive scaling capabilities over and above traditional RDBMS systems, it doesn't seem compelling for a standard e-commerce site. I doubt I would ever run into a client scenario where a NoSql solution would be a requirement or a good fit. I suppose an XML data store could count as a NoSql implementation as well. I could see the value of that type of solution to open the shopping cart solution up to more shared hosting deployments. With enough designer tools and end-user customization and configuration through the administration interface, it could open a shopping cart up to a larger do it yourself non-techy market |
Best regards, Shan Plourde www.pahsah.com+1 (416) 628-1280 -------------------------------- |
|
|
|
|
|
Rank: Member
Joined: 11/5/2003(UTC)
Posts: 1,786
|
While the transactional parts of an e-commerce like, like Checkout, should probably use a relational backing store for reliability, the catalog/content portion might benefit from some NoSql options.
One developer benefit is that you can concentrate on domain driven design with objects because there is no impedance mismatch between objects and datastore like there can be with SQL tables.
Again, I don't expect to integrate a NoSQL option into BV anytime soon but do want to ensure that we're keeping an eye on possible future technologies.
|
|
|
|
|
|
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.