Glynn said:
Hi Albert,
I appreciate your feedback and understand that SharePoint should not be a
replacement for a relational database.
However, acting on thousands of rows in large tables is one thing, but
taking 45 seconds to delete 100 rows in a sharepoint list is another.
Unfortunately it not another issue. It is the nature of how the connection
to those lists work. The data processing is done local, and it done record
by record. There is not a lot you can do when all processing has to occur
client side. Your hands are tied in this fashion.
If each delete record goes up the wire individually, would an approach
that
uses web services, a.k.a. Using Microsoft Windows SharePoint Services with
the Microsoft Office System,
http://msdn.microsoft.com/en-us/library/aa159897(office.11).aspx improve
performance?
Well in those examples we don't see any sql delete commands. if you pull
down the those 100 records as one string, modify it and sent it back up, you
likely see better performance, but you sill pulled the WHOLE list down,
modify it, and then push up the whole list back.
We actually often in a better position using ms-access to update SharePoint
stuff because it does all the dirty work and allows us to deal with one
record at a time.
Or, would a Visual Studio VB.Net client using web services eliminate the
indvidual record issue or would it encounter similar performance problems
as
Access.
See above, it might, but few have bothered to test this. And, it not going
to be a great solution that works with ms-access anyway. (but, why not
write a few lines of code and try it out?).
As mentioned, ms-access does a great job of allow you to deal
with one record at a time out of those lists now. Part of this issue is
really the nature of client server, but *ALSO* that of a
design that allows off-line disconnected mode also. And, there is also need
for scalability to 1000's of users. (if not 100's of thousands of users).
It is really a different way of thinking. If you goal is to write keyboard
heavy applications for the iPhone, and then ask how come there not better
keyboard support for the iPhone, the answer is it simply not the idea and
how it works.
So, it really comes down to a paradigm change, and thinking in old ways for
a different technology does not work well. The success of the SharePoint
platform is likely beyond what any would have imagined (fastest product to 1
billon in sales for Microsoft in their history).
So, like it not really practical to write a 3d video game in HTML, or
expect heaving word-processing or keyboard applications for the iPhone, the
world of a disconnected SharePoint list needs different considerations in
your designs.
As I have posted in MSDN Sharepoint Dev and Pgm'ing and Innovate on Office
forums, as well as MS Technet Office Sharepoint and Sharepoint Online
forums,
it is somewhat perplexing there are not more performance issues and
solutions.
True but it somewhat perplexing that we don't see 3d applications in HTML,
or applications that rely on lots of keyboarding for the iPhone. There all
good reasons for these issues. So, a company boss might have difficulty
grasping how come their employees can't do all their letter writing on their
iPhone since the boss just read an article that explains that some companies
find that with a iPhone their employees don't need a desktop computer
anymore.
We often see questions in this newsgroup about how come ms-access is slow.
After asking some more questions, we find they are trying to use a split
database over the internet. They then ask how come no addressed this problem
and how come ms-access over a wan to back end mdb file does not work? The
next question is how come there no articles helping one to boost performance
when using ms-access to a mdb back end over a lan? How come the industry is
not addressing this?
The answer here of course is that file share over a vpn with
ms-access does not work well at all, and it not suited. In a nutshell, the
answer to a split file share over the internet is DON'T do it!! The answer
sucks, but that is the reality here. The solution for the ms-access to an
mdb over a wan is to eliminate the mdb on the back end. (but, some people
can't seem to grasp this concept - note that you don't have this difficulty,
but I just putting this whole issue into perspective here). So, using
*DIFFERENT* methods and technology to grab that back end data is the
solution. In this case it would mean to move the data to Sql server, or even
sharepoint. In other words, the solution is not to make the mdb work over
the internet, but simply to NOT do that! You have to change how you work.
So, in effect your question is really much the same here. However, as I
mentioned, because SharePoint has just become so huge popular in such a
short time, there is a shortage of developers and information on
how to approach some of these issues. And, since SO MANY applications and
developers need to use that SharePoint data lists like sql tables, then we
are seeing HUGE efforts being placed into improving SharePoint lists
performance. MS has heard the needs of developers in regards to working
with SharePoint lists like sql data tables.
I mean MySql in early 2000's was all the rage, and yet it did not even have
referential integrity and cascade deletes, but if read the trade magazines
of that time you would think MySql was the 2nd coming. So, SharePoint stuff
is new, and you also need a bit of paradigm change in how you deal with and
use data.
When you look at something like eBay, they don't delete records, and when
they can avoid updating records, they do that too. So, for expired records,
they not even update some column for expiry, but simply filter records by
some kind of date stamp (can't afford the processing to update those
records). They then perhaps during some down time then scrub out old
records.
This is done for performance and scalability. So, differing solutions and
different approaches are often needed when you adopt different technologies.
A great example is that in ms-access (even for desktop, no network), our
designs REALLY need to avoid deleting records. So, if one can avoid creating
a temporary table(s) for reports, then one should. if you don't do this,
then we get serous bloat in the database.
If you cooking fish, it don't take a lot of heat and energy (a bit of steam
can cook it fast). However, a big rib roast needs some serious energy when
you cook it. Different horses for different courses is not only a lesson
in our IT industry, but is one of your daily life. The same concepts of
adapting for different situations when cooking or working in the IT industry
is not a whole lot different here.
Most of the time, it not climbing the mountain, but simply avoiding the
mountain all together that results in success in the IT industry.
ort/filepathname?query_string#anchor
.