1 |
HI |
2 |
|
3 |
I think it boils down to the product that you really know and is used to. |
4 |
|
5 |
I'm for example, is working at a telco where we prefer oracle, it is expensive |
6 |
yes, but it fullfills our needs of functionality, scalability and performance |
7 |
as well as we (internally) know the product very good. |
8 |
|
9 |
I think the same goes for mysql/postgresql, which product you're using is (for |
10 |
a major company) not that interesting but the benefits/costs are. |
11 |
|
12 |
That means does the product deliver what's needed and does their support |
13 |
really jump to our needs and problems? That's the basic problem we got, |
14 |
Oracle do, are not open source, and not free in terms of cost...... |
15 |
|
16 |
MySql and PostgrSQL are not free when it boils down to 24x7 support |
17 |
either..... |
18 |
|
19 |
It's all about business, what it's worth to you, and what you can afford... |
20 |
|
21 |
Personally by the way, I'm using mysql..... basic stuff, really don't know the |
22 |
cores of it |
23 |
|
24 |
--Robert |
25 |
|
26 |
|
27 |
On Thu 26 May 2005 06.36, kashani wrote: |
28 |
> Claudinei Matos wrote: |
29 |
> > About this topic, I want to know if postgresql may be a good choice |
30 |
> > instead of mysql. |
31 |
> > explain my case, I have a website with a intranet/extranet that uses |
32 |
> > postgresql as DB to stock a lot of data. Both of they will need to |
33 |
> > query a users table in DB to authenticate the users. |
34 |
> > What I want is to make just one users DB which one I can use to |
35 |
> > authenticate my web users, my email accounts (postfix + courier), the |
36 |
> > workstation login (linux workstations) and some samba clients. |
37 |
> > Considering that my website already use PostgreSQL, the development |
38 |
> > guys ask me about keep using only PostgreSQL. I think it could be a |
39 |
> > good idea since they will not have to change they sqls (mysql doesn't |
40 |
> > have support to all the things they commonly use) but I know postgre |
41 |
> > may be a bit slower then mysql and also a bit heavier. |
42 |
> > Did somebody have any experience of these type of authentication with |
43 |
> > postgres? Could the perfomance differences be meaningless? Or maybe it's |
44 |
> > better to do the effort to exchange the users DB to mysql? |
45 |
> > Note1: I already authenticate my email accounts with courier + mysql. |
46 |
> > Note2: In both ways I will use a separated server to run the DB. |
47 |
> |
48 |
> Break that into paragraphs next time, it's a little hard to parse. |
49 |
> |
50 |
> The performance difference between Mysql and Postgres is going to be |
51 |
> pretty negligible assuming we're not talking about a gigantic number of |
52 |
> user data. The tables will fit into RAM nicely and your selects are |
53 |
> going to be quick in either db. |
54 |
> |
55 |
> I would not recommend running Mysql and Postgres on the same server if |
56 |
> you're doing any sort of real traffic. Real traffic being highly |
57 |
> subjective to your workload, software, data size, and hardware. In my |
58 |
> environment I found that Mysql and Postgres on the same server |
59 |
> backend-ing some fairly heavy web sites cut performance to 60-70% of |
60 |
> what I'd see on the purely Mysql servers. Your mileage will vary greatly. |
61 |
> |
62 |
> In your case I'd break out a spread sheet and start comparing which |
63 |
> database your authentication software requires or supports. Assuming |
64 |
> both are equally supported I'd go with the db you're more comfortable |
65 |
> administrating. The amount of SQL either Mysql or Postgres supports is |
66 |
> not likely to play a part in your decision. |
67 |
> |
68 |
> Now I move into purely editorial mode |
69 |
> |
70 |
> Mysql and Postgres admins, developers, fans, etc come from two |
71 |
> different worlds. People who know what they are doing in Postgres seldom |
72 |
> know what they are doing on Mysql. And vice versa. Getting anyone who is |
73 |
> comfortable with their db platform to switch will be painful and is |
74 |
> going to require a mandate from on high. And someone who really knows |
75 |
> the new database is going to have double check code, db schema, |
76 |
> indexing, etc etc for the next 6 months. Because everyone is going to do |
77 |
> all the things that work in the old database that you should never, ever |
78 |
> do in the new database. And then complain about the new platform, loudly. |
79 |
> |
80 |
> I'm enforcing such a move this month and already hate every idiot |
81 |
> developer who was a fan of the old database platform who are thankfully |
82 |
> in the minority. I don't suggest doing such a move unless you have to. :( |
83 |
> |
84 |
> kashani |
85 |
-- |
86 |
gentoo-server@g.o mailing list |