: 4582 | 108638 | 12353
Please Fix the NSF 
New idea submissions, commenting and voting are no longer available on this site. Logins have also been disabled.
|
: 74 : 75 : 1 |
Please fix the NSF database
and by 'Fix' i mean:
1) Remove the obvious size limitations such as 32k view lookups, maximum field numbers and plain text field limits
2) Provide a good JDBC and .Net Drivers that enables access to the database from remote locations
3) Improve scaling (yes i know that it has huge theoretical size abilities but the performance degrades a lot when you add lots of documents or lots of views )
4) Externalise the View indexes
5) Provide Sharding in Clusters (optional)
The NSF has done us proud over the years and there have been lots of small improvements with each ODS structure update but it's still not what it should be (too many size limitations and performance problems), and this is the right time to fix it!!
WHY?
1) NoSQL is a growing product platform, estimated to be worth on par with the relational market within about 5 years
2) You already have a hell of a lot of experience in it.
3) You have a existing market for it (Notes apps), which it will help revitalise and is one of the final components in your ongoing "X" cause.
4) It will make money, if Oracle are busy building a proper NoSQL db platform then you know its a good idea. I know quite a few companies that would jump at the change of using a noSQL db from a trusted vendor.
5) The market is still young, you have time!!
You don't have to link it to Notes directly if you don't want to, stick it on the XWork server and call it XNSF or something if you feel like it (as long as Notes apps can access it). Yes I know you have recently given us good relational access, but relational is starting to look a bit old hat for a lot of webscale apps, we NEED a good NoSQL., CouchDb has shown you the way, and MongoDb has taken the ball and is running with it giving developer and businesses what they want, these 2 are the leaders in the document based NoSQL world.
|
1) daniele grillo596 (04 Nov 2011)
Very good point!
2) Giulio C686 (04 Nov 2011)
I support this idea because it resolves issues for millions of users that has Hung around since ibm acquired Lotus. But I think you'll have buckleys chance of maneuvering the ibm super tanker. Change takes so long for IBM to happen, they generally miss the opportunity. The usual response is to acquire a player in the market.
3) Mark Myers410 (04 Nov 2011)
@Giuilio good point, both of the lead players in this area would be pocket change for IBM to buy
4) Mike Woolsey5040 (04 Nov 2011)
Yeah, I looked up the NoSQL and Document model that Google came up with a few years ago and wondered why the Note format wasn't attaching to this. It's genius, and it's an important qualifier to demonstrate why relational databases often are not what you want.
Frankly, I've been working with SQL since 1984. And its limitations are very annoying -- such as updating key fields that meet certain criteria inside a relational join. Simple instructions in SQL are limited, even for relational work. That's where cursors came from. People need to start getting access to information about the limitations, and the "plusses" for alternative formats.
I'm not even terribly concerned about the field limitations -- though I'd always like more, particularly for BASIC (who cares about VisBasic's simplistic limits any more) and for the view itself. I can understand why the SUMMARY issue is a big deal, but I'd like more freedom to assign a field NONSUMMARY, and assign a huge field SUMMARY if I need to. Honestly, we're already costing ourselves huge amounts of time loading the b-tree on-disk. We should be able to benefit from that limited cost by allowing use of huge disk spaces.
Either that, or there's a need to assess the architecture. Either we work with small SUMMARYs and we should put 'em in memory, not on disk; or we work with big SUMMARYs and we should leave 'em on disk and optimize by partial-loading of the b-tree updates instead of loading & unloading huge btrees every time someone asks.
I'm sure this will cause a lot of evaluation. I'm sure it's a touchy subject, and I don't mean to pry it open for any more reason. And the developer has to have a lot of latitude to experiment and talk about all the horrible subtleties that are under there. Because views are an amazing piece of work. I realized that the first time I loaded the btree in a RAMdisk. Domino was a speed demon when I did that back when. So maybe with the advent of all this RAM, we can exploit it.
Frankly, I've been working with SQL since 1984. And its limitations are very annoying -- such as updating key fields that meet certain criteria inside a relational join. Simple instructions in SQL are limited, even for relational work. That's where cursors came from. People need to start getting access to information about the limitations, and the "plusses" for alternative formats.
I'm not even terribly concerned about the field limitations -- though I'd always like more, particularly for BASIC (who cares about VisBasic's simplistic limits any more) and for the view itself. I can understand why the SUMMARY issue is a big deal, but I'd like more freedom to assign a field NONSUMMARY, and assign a huge field SUMMARY if I need to. Honestly, we're already costing ourselves huge amounts of time loading the b-tree on-disk. We should be able to benefit from that limited cost by allowing use of huge disk spaces.
Either that, or there's a need to assess the architecture. Either we work with small SUMMARYs and we should put 'em in memory, not on disk; or we work with big SUMMARYs and we should leave 'em on disk and optimize by partial-loading of the b-tree updates instead of loading & unloading huge btrees every time someone asks.
I'm sure this will cause a lot of evaluation. I'm sure it's a touchy subject, and I don't mean to pry it open for any more reason. And the developer has to have a lot of latitude to experiment and talk about all the horrible subtleties that are under there. Because views are an amazing piece of work. I realized that the first time I loaded the btree in a RAMdisk. Domino was a speed demon when I did that back when. So maybe with the advent of all this RAM, we can exploit it.
5) Mike Woolsey5040 (04 Nov 2011)
Oh, the reason I'm not concerned about field limitations: I always ask how large the VARCHAR is in Oracle when someone complains about Notes on this count.
6) Mark Demicoli11792 (05 Nov 2011)
I can't help but recognise from a starting point that what we have now is and always has been an absolute travesty for productivity. Denounced for years for not being relational, NSF has casually (if ambiguously like a hated offspring) made itself quietly important again if only by coincidence, for being so flexible and 'unstructured'. I'll vote this one up because there are always improvements to be had.
7) Rob Wills1025 (05 Nov 2011)
IBM actually owned a couple of excellent NoSQL databases (UniVerse and Unidata collectively called U2) but recently sold them off. I don't get it really.
{ Link }
{ Link }
8) Peter Neidhart689 (06 Nov 2011)
make ODS more robust und fix fixup. We often had the case that after a server crash databases are corrupted bejond repair. Fixup just gave up. Also, server/applications crash because of faulty documents but fixup is unable to correct or even find them.
9) Vlad Sh10448 (06 Nov 2011)
@3 (Mark)
Lotus and FileNet have already been bought, it's time to start doing something :)
Lotus and FileNet have already been bought, it's time to start doing something :)
10) Vlad Sh10448 (06 Nov 2011)
> 4) Externalise the View indexes
Excellent!
Excellent!
11) Bill Buchan585 (07 Nov 2011)
Long overdue.
---* Bill
---* Bill
12) Gaby Spaszewski278 (30 Nov 2011)
Also please get rid of the 64GByte limit (not just via DAOS but 'really') and don't forget native support on IBM i if you decide to go for a new kind of nsf :-)
13) Mark Demicoli11792 (30 Nov 2011)
I think we have a change of getting some progress here because xPages does still depend on NSF, unless ofcourse there are secret plans to change that aswell. Come on IBM, yes we told you DB2 as a backend is like retrofitting an elephant with trolley wheels and you quietly abandoned it over time, but we won't run salt into the wound. Please oh please get moving on Notes/Domino before CouchDB swallows you up...
14) Mark Demicoli11792 (30 Nov 2011)
change=chance
Welcome to IdeaJam™
You can run IdeaJam™ in your company. It's easy to install, setup and customize. Your employees, partners and customers will immediately see results.
Use IdeaJam to:
- Collect ideas from employees
- Solicit feedback and suggestions from employees and customers
- Run innovation contests and competitions
- Validate concepts
- Use the power of "crowd-sourcing" to rank ideas and allow the best ideas to rise to the top
IdeaJam™ works with:
- IBM Connections
- IBM Lotus Quickr
- Blogs and Wikis
- Websphere Portal
- Microsoft Sharepoint
- and other applications.
IdeaJam has an extensive set of widgets and API's that allow you to extend and integrate IdeaJam™ with other applications.
Learn more about IdeaJam >>
25 | Option ExtendedSyntax False (or NotesDocumentExtended False) |
2 | Use more customization features in ND9 NotesMail |
-1 | How to Connect Windows Active Directive Group? |
IdeaJam developed by
