• Toll-free  888-665-8637
  • International  +1 717-220-0012
Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

shanplourde
#1 Posted : Tuesday, September 28, 2010 7:31:13 AM(UTC)
shanplourde

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
--------------------------------
Marcus
#2 Posted : Tuesday, September 28, 2010 7:34:49 AM(UTC)
Marcus

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.
shanplourde
#3 Posted : Tuesday, September 28, 2010 1:03:48 PM(UTC)
shanplourde

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
--------------------------------
Marcus
#4 Posted : Tuesday, September 28, 2010 1:04:53 PM(UTC)
Marcus

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.
Kman
#5 Posted : Wednesday, September 29, 2010 1:10:08 PM(UTC)
Kman

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
Regards,
Kim(Kman) Rossey
www.toocoolwebs.com
BVSoftware - MerchantTribe Programming/Design, Database Programming and Business Applications
[email protected]
shanplourde
#6 Posted : Wednesday, September 29, 2010 7:43:27 PM(UTC)
shanplourde

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
--------------------------------
Marcus
#7 Posted : Wednesday, September 29, 2010 7:45:59 PM(UTC)
Marcus

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.

©2024 Develisys. All rights reserved.
  • Toll-free  888-665-8637
  • International  +1 717-220-0012