Showing posts with label customer. Show all posts
Showing posts with label customer. Show all posts

Wednesday, March 21, 2012

Need Customer & Sales Database Designed /for Internet Sales Business

I'm looking for someone to either redesign the Northwind Access
customer database supplied by Microsoft (I've modified it some myself
and have been using a similar system for two years). Alternatively,
write a completely different system using SQL instead of Access. I must
be able to modify all HTML/ASP. It's unlikely I'll be interested in
any system requiring a subscription service of some type. Every small
detail of the system need not be designed. I can use Dreamweaver to
modify most HTML/ASP pages but giving me a basic system with
substantial functionality would be best to start with. I will consider
another database but SQL seems to be the most promising for my
application.

Please advise if anyone can assist in the programming or knows of a
reasonably price programmer.aaron_kempf@.Hotmail.com

aaron.kempf@.gmail.com
email me what you want ill do it

i use dreamweaver also

Monday, March 19, 2012

Need ammunition against 'clustered index hampers performance'

(alexander.arvidsson@.gmail.com) writes:

Quote:

Originally Posted by

The creators of the software that my customer uses (two different
systems) BOTH claim that using clustered indexes hampers performance,
each and every time. I can't find ANY resource on the internet that
validates this, quite the opposite. I am told that the best practices
is to always us a clustered index on a table.
Following their own guidelines, there is no clustered index in sight,
and hence some tables have a whopping 30GB(!) of unused space.


SQL Server MVP Greg Linwood has argued fiercely for heaps, but it is
obvious that heaps require much more manual management. Else, you end
up with badly fragmented tables, as in your customer's case.

But if the developers think that clustered index is worse than sin, then
just set up a job that adds a clustered index to the table and then
drops it. It will run for a longer time than a regular reindexing,
as all non-clustered indexes will have to be rebuilt. Twice. Or drop
the non-clustered indexes first, and then add them back at the end.

Hopefully, someone will object to this and ask "isn't there a
simpler way?", whereupon you answer "sure, we could use a clustered
index instead, but it takes price to be on top".

If you can find the resources to set up a parallel environment as
DA suggested, then it should be an easy game.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspxA parallel environment would be the best, but in this case I'll have
no such luck. I was a bit surprised to see that there is some dissent
as to what type of indexes to use. Don't get me the the wrong way; I
certainly understand that everything has its time and place, but I've
been fed that clustered indexes is the way to go, all the way, every
day, practically since I started with SQL Server. I'll burrow down in
Greg's blog and probably pick up Kalen Delaney's book as well.

A huge thanks to all of you for giving me perhaps not the answer I was
expecting, but instead something to ponder for quite a while :)|||(alexander.arvidsson@.gmail.com) writes:

Quote:

Originally Posted by

A parallel environment would be the best, but in this case I'll have
no such luck. I was a bit surprised to see that there is some dissent
as to what type of indexes to use. Don't get me the the wrong way; I
certainly understand that everything has its time and place, but I've
been fed that clustered indexes is the way to go, all the way, every
day, practically since I started with SQL Server. I'll burrow down in
Greg's blog and probably pick up Kalen Delaney's book as well.


Let me put it this way: a formula one race car is much faster than a
standard car. But if you want to go from Stockholm to Malm, you may
still make that trip faster with a standard car if you travel along.
The F1 car needs much more support and maintenance.

Greg has a very strong experience in the perf-tuning field, but his
advice is not for every one.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

Monday, March 12, 2012

Need Advice on Reporting, End User Query and Data warehousing Tools

Hi:
I need an advice on Reporting, End User Query and Data warehousing
Tools
Below is my customer requirement:
Reporting:
- Flexible Reporting and Web Publishing
- Development and / or customization of reports by systems users using
a GUI based reports designer
- Export Capability to Office Automation Software
- Charting Facility
- Browser-Based User Interface
End User Query:
- Export Capability to Office Automation Software
- Web Publishing Output
- Charting Facility
- Reporting Facility
- Browser-Based User Interface
- Performance Monitoring/Tracking
- Administration
- Row and Column Level Security
Data warehouse:
- ETL and Analyst Tools
SQL2005 Enterprise, SSIS, SSAS, SSRS and Report Builder seem to meet
the requirement, but the problem is the target database is Oracle10g,
can i use those services on Oracle database ?
How about the solution from BusinessObject and Microstrategy, compare
with the services from SQL2005 Enterprise ?
Please Help.
Thanks
JCvoonHi
Reporting Services will certainly cover all your reporting needs including
the automatic generation and delivery that you have specified. You may want
to read the articles at
http://www.microsoft.com/sql/technologies/reporting/default.mspx if you have
not already. It sounds like you will not be running reports directly of you
Oracle database (which I think is possible although I have no experience of
doing this), but using Analysis Services will eliminate the need query this
data http://www.microsoft.com/sql/technologies/analysis/default.mspx.
An important factor will be a good design of the data warehouse. A poor
design will make reporting significantly more difficult, regardless of the
tool used. After using Business Objects a little I would say that for report
generation I do prefer Reporting Services.
One of the biggest factors may be licencing costs, if you are already a SQL
Server house, you will have not extra licence costs for AS or RS.
HTH
John
"jcvoon" wrote:
> Hi:
> I need an advice on Reporting, End User Query and Data warehousing
> Tools
> Below is my customer requirement:
> Reporting:
> - Flexible Reporting and Web Publishing
> - Development and / or customization of reports by systems users using
> a GUI based reports designer
> - Export Capability to Office Automation Software
> - Charting Facility
> - Browser-Based User Interface
> End User Query:
> - Export Capability to Office Automation Software
> - Web Publishing Output
> - Charting Facility
> - Reporting Facility
> - Browser-Based User Interface
> - Performance Monitoring/Tracking
> - Administration
> - Row and Column Level Security
> Data warehouse:
> - ETL and Analyst Tools
>
> SQL2005 Enterprise, SSIS, SSAS, SSRS and Report Builder seem to meet
> the requirement, but the problem is the target database is Oracle10g,
> can i use those services on Oracle database ?
> How about the solution from BusinessObject and Microstrategy, compare
> with the services from SQL2005 Enterprise ?
> Please Help.
> Thanks
> JCvoon
>|||John Bell:
Thanks for your reply.
In fact I plan to use the SSRS to generate report from Oracle database,
and use SSIS to build the Oracle data warehouse, for SSRS I think it
shouldn't be a problem, but for SSIS and SSAS I'm not sure.
Regards
JCVoon

Friday, March 9, 2012

Need a Suggestion for creating Tables ?

One of my Customer deals in different Items, and every Item has different
specifications and types.
For example:
Item A has different categories, types, colours
Item B has different colours, sizes, thickness, weight
Item C has different colours, qualities, yarn counts, widths, types, weave,
design type
Now how can I create my Product Table(s) which should accomodate all above.
How many tables I have to create, is it possible that I create one or two
tables and use self aliasing, if possible, how ?
One easy way is to create different tables for all the required
specifications, but what, if customer deals with 100s of specifications all
over, and another customer whom I sell this product, deals with another 100
specifications which are totally different than the last customer ?
Please give me your best solutions so that I can easily use these tables in
my Inventory Application, without changing the design again and again.
I hope you understand what I am trying to say ?
I am developing my Application in VB.Net 2005.
Best Regards,
LuqmanSee if this helps. Read about "Entity Supertypes and Subtypes".
http://72.14.203.104/search?q=cache...s&ct=clnk&cd=17
AMB
"Luqman" wrote:

> One of my Customer deals in different Items, and every Item has different
> specifications and types.
> For example:
> Item A has different categories, types, colours
> Item B has different colours, sizes, thickness, weight
> Item C has different colours, qualities, yarn counts, widths, types, weave
,
> design type
> Now how can I create my Product Table(s) which should accomodate all above
.
> How many tables I have to create, is it possible that I create one or two
> tables and use self aliasing, if possible, how ?
> One easy way is to create different tables for all the required
> specifications, but what, if customer deals with 100s of specifications al
l
> over, and another customer whom I sell this product, deals with another 10
0
> specifications which are totally different than the last customer ?
> Please give me your best solutions so that I can easily use these tables i
n
> my Inventory Application, without changing the design again and again.
> I hope you understand what I am trying to say ?
> I am developing my Application in VB.Net 2005.
>
> Best Regards,
> Luqman
>
>|||Any practical example of table(s) and queries will be helpful.
Best Regards,
Luqman
"Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in message
news:7DF777AC-4DE8-4BE0-BB98-946BB6FDC3B5@.microsoft.com...
> See if this helps. Read about "Entity Supertypes and Subtypes".
> http://72.14.203.104/search?q=cache...s&ct=clnk&cd=17
>
> AMB
> "Luqman" wrote:
>

Monday, February 20, 2012

nchar or char or nvarchar or varchar??

Hi,
Which of the above data type (alongwith size) should be used for storing things like Customer Name, Company name etc . ?
Also, what really is the benefit of one over the over :confused:
ThanksOriginally posted by Joozh
Hi,

Which of the above data type (alongwith size) should be used for storing things like Customer Name, Company name etc . ?

Also, what really is the benefit of one over the over :confused:

Thanks

the difference between char and varchar is that: char is a fixed length datatype meaning, if suppose u have char(8) and you store a value say 'Harsh' in this variable then it gets stored a 'Harsh___' where at the right the remaining space is padded with blanks, in short all the 8 bits are utilised.
whereas if it would have been a varchar(8) it would have saved it as 'Harsh' meaning only the exact required size is allocated which is 5 in this case.
When you want to store the data in unicode format use nchar or nvarchar .|||Thanks harshal_in :-) :)

That clarifies... One last quick question:

Is it okay to assume then that the best approach is to use nvarchar OR varchar?|||nvarchar uses double the amount of storage compared to varchar, so use varchar unless you need to store double byte data (eg japanese, chinese)|||Originally posted by Joozh
Thanks harshal_in :-) :)

That clarifies... One last quick question:

Is it okay to assume then that the best approach is to use nvarchar OR varchar?

Don't use the NVARCHAR or NCHAR data types unless you need to store 16-bit character (Unicode) data. They take up twice as much space as VARCHAR or CHAR data types, increasing server I/O and wasting unnecessary space in your buffer cache.

If the text data in a column varies greatly in length, use a VARCHAR data type instead of a CHAR data type. The amount of space saved by using VARCHAR over CHAR on variable length columns can greatly reduce I/O reads, improving overall SQL Server performance.

Another advantage of using VARCHAR over CHAR columns is that sorts performed on VARCHAR columns are generally faster than on CHAR columns. This is because the entire width of a CHAR column needs to be sorted.|||There are some advantages to using the CHAR and NCHAR types, but those advantages are somewhat esoteric. If you want more information see Kalen Delaney's Inside SQL Server 2000 (http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=mHu18NPJNB&isbn=0735609985&itm=1) (which I see as a "must read" for a SQL geek anyway).

Basically it boils down to bookkeeping. Variable length columns require the DBE (data base engine) to compute both the start and the length of the variable columns. This adds considerable overhead at the row manager level, which makes access to all of the columns in a row with variable width columns take longer. This isn't significant in most cases, but it does matter for bulk loads and similar operations. Particularly for staging very large warehouses, it can be significant.

-PatP|||But the size of the row can be just as much a performance factor...

For example Char(255) will store all of that...now think about returning all the data, as comp[ared to what is just there...

I beleive a rule of thumb is something like 10 chars...

10 or less make char, otherwise varchar...

Pat?|||It is actually more complicated than that, but you could approximate the rule by using: If the maximum column length minus the minimum column length is more than 10 characters, then use a variable length column. I still say you should just read the book so you'll understand the gist of the rule (and 10,000 other important things) and the factors that weigh into it, but the approximation is a lot better than nothing.

-PatP