需要经验丰富的开发人员提供设计 - 改造建议 [英] Design-rehaul advice needed from experienced developers
问题描述
我刚刚来到一家汽车经纪公司工作。我的
职位包括在
命令中执行神秘的仪式，仪式和魔法，以便从他们的访问数据库中获取信息。这是由于设计师这一事实所致。他们雇用了一个令人遗憾的能力来讨论一个远远超出她能力范围的计划。她对数据库设计的任何原则都没有任何概念，所以我剩下的就是一个垃圾堆。
一个垃圾堆。我不能重新开始的唯一原因是...... ....所有数据都需要保存
。
所以这里是'煮沸精华：
人们访问我们公司想买车。我们的销售人员之一
找到他们想要的汽车（使用经销商库存数据库，汽车销售额等等）并以价格回来。这个人（或夫妇）说
好吧我们想买它。他们喜欢它，成为回头客，推荐
朋友等。
售完后，我得到一件交易夹克。包含
促销的所有细节。我必须将这些信息数据输入一个可怕的橙色
前端，然后
形式后面的跛脚变异放射性hedgehod对数据进行打击并将其放入错误标记的小窝中。 />
现在存在的数据库是 - 支持 - 允许我们输入
" deals，"这基本上是汽车销售的行话。然后我们可以说b / b
涉嫌审计数据，验证日期，盘子寄出时，制作
月报等等。
数据库结构因为它是惊人的，除非你是一个强大的紧张症，它应该让你至少傻笑。 （我的反应
当然不是那么轻松）
1表" Customers"
1 table "加帽QUOT; （帽子是出售金融统计的行话，
，这意味着交易已经敲定或上限。）
[客户：]
销售日期
名称
配偶
地址/电话
车辆年份
车辆制造/型号
新/使用
VIN
经销商
顾问（我们的销售人员）
推荐来源
财务人员
[CAPS]
销售日期
名称
促销价
我们的费用
MBI
额外费用
额外金额
减少开支
顾问名字缩写（2个字符）
佣金
2表格由三个字段相关，主要是销售日期，姓氏，
和名字。这意味着客户与客户之间不存在一对多的关系。和销售，无视
客户表不是真正的客户表，而且Cap表格不是
真正代表销售。
我关心核心设计。我没有研究过规范化
但是我有RDMS的基本（看起来很直观）的想法。
我不打算修复当前数据库。前端是完全无用的，而且桌子都是垃圾。我从头开始
但仍需要将旧数据放入新表中。这个
会产生一个严重的问题，在一分钟内描述。无论如何，
我最需要创建一个新的表模式，这就是我想要建议的地方。
我目前的想法是：
模拟我们业务的最佳方式可能是创建一个逻辑实体
Customer和逻辑实体销售。或者三个：客户，
EntitySold和Sale。这样就可以选择记录销售除了保修和安全产品等汽车以外的其他东西。我的愿景
与桌子接口的最佳形式将是处理
客户作为主要数据实体，可以搜索客户，
然后，当客户被选中时，所有与该客户相关的信息都将可用，
当然包括他购买汽车的历史记录。和我们一起。
问题在于如何关联这些实体。就我的想法而言，跟踪客户的唯一方法是使用一个特定于他们的人的钥匙
：SS＃，驾驶执照，等等。
我没看到如何使用任意数字。我不认为
认为我能够获得SS＃s，所以我认为我唯一的选择是开始
要求销售部门获得司机许可证号码和
表示要求限制他们的交易。
假设到目前为止我的帽子是直接的，那么<与客户及其销售相关的
意味着与两个字段相关的Sale表中的Customer表相关
，DriversLicence＃和
DriversLicenceState 。
现在我想到了这个问题。假设我可以创建这个新的
dabatase结构，并煞费苦心地将旧数据转换为新的
衣服。基本上，我会在每张表中都有旧数据
缺少一个密钥（DriversLicense），这与客户的销售有关。
他的销售。即使我要给那些旧的数据任意键
来维持他们的关系，这也会带来各种新的问题，我可能不需要这些问题。枚举。
无论如何，这是我逐渐消失的地方，因为我没有任何经验
。到目前为止，有人能就我的想法给我一些建议吗？
我可能会从这里出发？我必须承认，我感觉有点不知所措。
感谢您阅读我的小说，
John
ps
我正在运行Access 2000 mdb
I''m just recently come to work for an auto brokerage firm. My
position involves performing mysterious rites, rituals and magick in
order to get information out of their access database. This is due to
the fact that the "designer" they hired had an unfortunate ability to
tink around with a program far beyond her reach. She had no concept
of any of the principles of database design, so what i''m left with is
a junkpile. The only reason I can''t start all over?....all the data
needs to be saved.
So here''s the boiled down essence:
People visit our company wanting to buy a car. One of our sales guys
locates the car they want (using dealer inventory databases, car
sales, etc) and comes back with a price. The person (or couple) say
okay we want to buy it. They love it, become repeat customers, refer
friends, etc.
After the sale, I get a "deal jacket" with all the details of the
sale. I have to dataenter this information into a horrid orange
frontend and then the lame mutated radioactive hedgehod behind the
form shits on the data and puts it in mismarked cubbyholes.
The database as it exists now is -supposed- to allow us to enter
"deals," which is basically jargon for a car sale. Then later we can
allegedly audit data, verify dates, when plates were mailed, create
monthly reports, etc.
The database structure as it is frightning, and unless you''re
massively catatonic it should make you at least giggle. (My reaction
of course isn''t so light-hearted)
1 table "Customers"
1 table "Caps" (caps is jargon for the financial tallying of the sale,
which means the deal has been finalized, or "capped.")
[Customers:]
Sale Date
Names
Spouse
Address/Phone
Vehicle Year
Vehicle Make/Model
New/Used
VIN
Dealer
Consultant (our sales guy)
Referral Source
Financer
[CAPS]
Sale Date
Names
Sale Price
Our Cost
MBI
Extras
Extras Amount
Less Expenses
Consultant Initials (2 chars)
Commission
The 2 tables are related by three fields, mainly Sale Date, Last Name,
and First Name. This means there can be no one-to-many relationship
between a "Customer" and a "Sale," disregarding the fact that the
Customer table isn''t really a customer table and the Cap table doesn''t
really represent a sale.
I''m concerned here with core design. I haven''t studied normalization
but I have the basic (what seems to be intuitive) idea of RDMS.
I am not going to fix the current database. The front end is
completely useless and the tables are junk. I''m starting from scratch
but will still need to get the old data into the new tables. This
will create a serious problem, described in a minute. Anyway,
utlimately I need to create a new table schema and that''s where I
would like advice.
My current thoughts are:
The best way to model our business might be to create a logical entity
"Customer" and a logical entity "Sale." Or maybe three: Customer,
EntitySold, and Sale. This would allow the option of logging sales of
things other than cars like warranties and safety products. My vision
for the best form of interfacing with the tables would be treating
Customers as the primary data entity, Customers could be searched,
edited, actions perfomed upon, etc. Then, when a customer is
selected, all information relating to that customer will be available,
including of course his history of car purchases with us.
The problem then is how to relate these entities. As far as my
thinking is concerned, the only way to track customers is to use a key
for them that is specific to their person: SS#, Drivers license, etc.
I don''t see how using arbitrary numbers would be possible. I don''t
think i''ll be able to get SS#s, so I think my only option is to start
requiring the sales department to get Driver''s licence numbers and
states as a requirement to capping their deals.
Assuming I have my hat on straight so far, the central task of
relating customers and their sales would mean a Customer table related
to the Sale table(s) related by two fields, DriversLicence# and
DriversLicenceState.
And now onto the problem I forsee. Assuming I can create this new
dabatase structure and painstakingly get the old data into its new
clothes. I''m going to have, essentially, old data in each table
lacking a key (DriversLicense), that which relates the customer with
his sale(s). And even if I were to give that old data arbitrary keys
to maintain their relationship, that brings up all kinds of new
problems which I probably don''t have to enumerate.
Anyway, this is where I peter out because I don''t have any experience
with this. Can someone give me some advice on my thoughts so far and
where I might go from here? I must admit I''m feeling slightly
overwhelmed.
Thank you for reading my novellete,
John
p.s.
I''m running Access 2000 mdb
推荐答案
当同一个客户回来换另一辆车（你想要
重复客户，没有？）你的布局是免费的。
你可以从头创建一个新的数据库如果您知道
如何编写Append和MakeTable查询，则保存数据。显然你不是。我可以告诉你，如果你希望能够建立一个可扩展的数据库，你将需要更多的表，而不是你想要的。使用你描述的2张桌子
，当你第100次销售时，你将会没有Camaro
。如果没有
运行多个冗余查询，那么您认为所有那些能够提供的报告都无法创建。
只要告诉你的老板一个真正的数据库设计师就可以了。
正确。否则你只是把手指放在堤坝上（或者按照我喜欢的方式使用B $ bEllen Degeneres）。然后你可以成为管理员和
一切都很好。
2月26日下午4:54，JohnH < JohnHarri ... @ gmail.comwrote：
And when the same customer comes back for another vehicle (you DO want
repeat customers, no?) your layout is phuxored.
You can create a new DB from scratch with the saved data if you know
how to write Append and MakeTable queries. Apparently you don''t. I
can tell you you''re going to need more tables than you say you will if
you want to be able to make a scalable database. Using the 2 tables
you described, you''re going to be up shit''s creek without a Camaro
when you hit your 100th sale. All those reports you think you''re
going to be able to pull aren''t going to be possible to create without
running multiple redundant queries.
Just tell your boss to pony up for a real database designer to do it
properly. Otherwise you''re just sticking your finger in the dyke (or
"Ellen Degeneres" as I like to put it). Then you can be the admin and
all is well.
On Feb 26, 4:54 pm, "JohnH" <JohnHarri...@gmail.comwrote:
我刚刚来到一家汽车经纪公司工作。我的
职位包括在
命令中执行神秘的仪式，仪式和魔法，以便从他们的访问数据库中获取信息。这是由于设计师这一事实所致。他们雇用了一个令人遗憾的能力来讨论一个远远超出她能力范围的计划。她对数据库设计的任何原则都没有任何概念，所以我剩下的就是一个垃圾堆。
一个垃圾堆。我不能重新开始的唯一原因是...... ....所有数据都需要保存
。
所以这里是'煮沸精华：
人们访问我们公司想买车。我们的销售人员之一
找到他们想要的汽车（使用经销商库存数据库，汽车销售额等等）并以价格回来。这个人（或夫妇）说
好吧我们想买它。他们喜欢它，成为回头客，推荐
朋友等。
售完后，我得到一件交易夹克。包含
促销的所有细节。我必须将这些信息数据输入一个可怕的橙色
前端，然后
形式后面的跛脚变异放射性hedgehod对数据进行打击并将其放入错误标记的小窝中。 />
现在存在的数据库是 - 支持 - 允许我们输入
" deals，"这基本上是汽车销售的行话。然后我们可以说b / b
涉嫌审计数据，验证日期，盘子寄出时，制作
月报等等。
数据库结构因为它是惊人的，除非你是一个强大的紧张症，它应该让你至少傻笑。 （我的反应
当然不是那么轻松）
1表" Customers"
1 table "加帽QUOT; （帽子是出售金融统计的行话，
，这意味着交易已经敲定或上限。）
[客户：]
销售日期
名称
配偶
地址/电话
车辆年份
车辆制造/型号
新/使用
VIN
经销商
顾问（我们的销售人员）
推荐来源
财务人员
[CAPS]
销售日期
名称
促销价
我们的费用
MBI
额外费用
额外金额
减少开支
顾问姓名缩写（2个字符）
佣金
这两个表由三个字段相关，主要是销售日期，姓氏，
和名字。这意味着客户与客户之间不存在一对多的关系。和销售，无视
客户表不是真正的客户表，而且Cap表格不是
真正代表销售。
我关心核心设计。我没有研究过规范化
但是我有RDMS的基本（看起来很直观）的想法。
我不打算修复当前数据库。前端是完全无用的，而且桌子都是垃圾。我从头开始
但仍需要将旧数据放入新表中。这个
会产生一个严重的问题，在一分钟内描述。无论如何，
我最需要创建一个新的表模式，这就是我想要建议的地方。
我目前的想法是：
模拟我们业务的最佳方式可能是创建一个逻辑实体
Customer和逻辑实体销售。或者三个：客户，
EntitySold和Sale。这样就可以选择记录销售除了保修和安全产品等汽车以外的其他东西。我的愿景
与桌子接口的最佳形式将是处理
客户作为主要数据实体，可以搜索客户，
然后，当客户被选中时，所有与该客户相关的信息都将可用，
当然包括他购买汽车的历史记录。和我们一起。
问题在于如何关联这些实体。就我的想法而言，跟踪客户的唯一方法是使用一个特定于他们的人的钥匙
：SS＃，驾驶执照，等等。
我没看到如何使用任意数字。我不认为
认为我能够获得SS＃s，所以我认为我唯一的选择是开始
要求销售部门获得司机许可证号码和
表示要求限制他们的交易。
假设到目前为止我的帽子是直接的，那么<与客户及其销售相关的
意味着与两个字段相关的Sale表中的Customer表相关
，DriversLicence＃和
DriversLicenceState 。
现在我想到了这个问题。假设我可以创建这个新的
dabatase结构，并煞费苦心地将旧数据转换为新的
衣服。基本上，我会在每张表中都有旧数据
缺少一个密钥（DriversLicense），这与客户的销售有关。
他的销售。即使我要给那些旧的数据任意键
来维持他们的关系，这也会带来各种新的问题，我可能不需要这些问题。枚举。
无论如何，这是我逐渐消失的地方，因为我没有任何经验
。到目前为止，有人能就我的想法给我一些建议吗？
我可能会从这里出发？我必须承认，我感觉有点不知所措。
感谢您阅读我的小说，
John
ps
我正在运行Access 2000 mdb
I''m just recently come to work for an auto brokerage firm. My
position involves performing mysterious rites, rituals and magick in
order to get information out of their access database. This is due to
the fact that the "designer" they hired had an unfortunate ability to
tink around with a program far beyond her reach. She had no concept
of any of the principles of database design, so what i''m left with is
a junkpile. The only reason I can''t start all over?....all the data
needs to be saved.
So here''s the boiled down essence:
People visit our company wanting to buy a car. One of our sales guys
locates the car they want (using dealer inventory databases, car
sales, etc) and comes back with a price. The person (or couple) say
okay we want to buy it. They love it, become repeat customers, refer
friends, etc.
After the sale, I get a "deal jacket" with all the details of the
sale. I have to dataenter this information into a horrid orange
frontend and then the lame mutated radioactive hedgehod behind the
form shits on the data and puts it in mismarked cubbyholes.
The database as it exists now is -supposed- to allow us to enter
"deals," which is basically jargon for a car sale. Then later we can
allegedly audit data, verify dates, when plates were mailed, create
monthly reports, etc.
The database structure as it is frightning, and unless you''re
massively catatonic it should make you at least giggle. (My reaction
of course isn''t so light-hearted)
1 table "Customers"
1 table "Caps" (caps is jargon for the financial tallying of the sale,
which means the deal has been finalized, or "capped.")
[Customers:]
Sale Date
Names
Spouse
Address/Phone
Vehicle Year
Vehicle Make/Model
New/Used
VIN
Dealer
Consultant (our sales guy)
Referral Source
Financer
[CAPS]
Sale Date
Names
Sale Price
Our Cost
MBI
Extras
Extras Amount
Less Expenses
Consultant Initials (2 chars)
Commission
The 2 tables are related by three fields, mainly Sale Date, Last Name,
and First Name. This means there can be no one-to-many relationship
between a "Customer" and a "Sale," disregarding the fact that the
Customer table isn''t really a customer table and the Cap table doesn''t
really represent a sale.
I''m concerned here with core design. I haven''t studied normalization
but I have the basic (what seems to be intuitive) idea of RDMS.
I am not going to fix the current database. The front end is
completely useless and the tables are junk. I''m starting from scratch
but will still need to get the old data into the new tables. This
will create a serious problem, described in a minute. Anyway,
utlimately I need to create a new table schema and that''s where I
would like advice.
My current thoughts are:
The best way to model our business might be to create a logical entity
"Customer" and a logical entity "Sale." Or maybe three: Customer,
EntitySold, and Sale. This would allow the option of logging sales of
things other than cars like warranties and safety products. My vision
for the best form of interfacing with the tables would be treating
Customers as the primary data entity, Customers could be searched,
edited, actions perfomed upon, etc. Then, when a customer is
selected, all information relating to that customer will be available,
including of course his history of car purchases with us.
The problem then is how to relate these entities. As far as my
thinking is concerned, the only way to track customers is to use a key
for them that is specific to their person: SS#, Drivers license, etc.
I don''t see how using arbitrary numbers would be possible. I don''t
think i''ll be able to get SS#s, so I think my only option is to start
requiring the sales department to get Driver''s licence numbers and
states as a requirement to capping their deals.
Assuming I have my hat on straight so far, the central task of
relating customers and their sales would mean a Customer table related
to the Sale table(s) related by two fields, DriversLicence# and
DriversLicenceState.
And now onto the problem I forsee. Assuming I can create this new
dabatase structure and painstakingly get the old data into its new
clothes. I''m going to have, essentially, old data in each table
lacking a key (DriversLicense), that which relates the customer with
his sale(s). And even if I were to give that old data arbitrary keys
to maintain their relationship, that brings up all kinds of new
problems which I probably don''t have to enumerate.
Anyway, this is where I peter out because I don''t have any experience
with this. Can someone give me some advice on my thoughts so far and
where I might go from here? I must admit I''m feeling slightly
overwhelmed.
Thank you for reading my novellete,
John
p.s.
I''m running Access 2000 mdb
First创建并测试一个新数据库，并使其像你想要的那样。一张纸上的
布局会有所帮助。
使用此作为模板，但不要从头开始创建表但是使用
进行表格查询。
First create and test a new database and make it like you want it. A
layout on a sheet of paper would help.
Use this as a template but don''t create tables from scratch but use
make table queries.
2月26日下午2:19，Ricks < rickyae ... @ gmail.comwrote：
On Feb 26, 2:19 pm, "Ricks" <rickyae...@gmail.comwrote:
首先创建并测试一个新数据库，并使其成为您想要的。一张纸上的
布局会有所帮助。
使用此作为模板，但不要从头开始创建表但是使用
进行表查询。
First create and test a new database and make it like you want it. A
layout on a sheet of paper would help.
Use this as a template but don''t create tables from scratch but use
make table queries.
我很感激人们的帮助，但Rick，你一定不能读b $ b读取我写的东西。
And ManningFan，我不想激怒你，但你似乎不在乎，
所以你为什么回应？
你的第一个句子假装在我身上露出了一些近视，但
只是大声说你是傲慢的：这个讨论的问题的全部要点是询问关于如何解决那个非常好的问题。另外，假设我明显不知道b $ b知道什么是什么意思呢？什么东西，没有证据？我的问题围绕着设计
的决定，抽象/理论，我非常感谢能够帮助我做出回应。但是你不能停下来听你自己说话大男子主义。当我提出问题时，我宁愿不被侮辱
，所以请不要发帖。
I appreciate people''s attempts to help, but Rick, you must not have
read what I wrote.
And ManningFan, I don''t want to flame you but you don''t seem to care,
so why did you respond?
Your first sentence feigns to reveal some myopia on my part, but
merely shouts that you''re arrogant: The entire point of this
discussion question was to ask for ideas on how to solve that very
problem. Also, what is the point in assuming what I "apparently don''t
know" something, without evidence? My question centers around design
decisions, abstract/theory, and I would be very grateful to get
responses that might help me in that ear. You however can''t stop
listening to yourself talk machismo. And I''d rather not be insulted
when I ask questions so stay out of my posts.
这篇关于需要经验丰富的开发人员提供设计 - 改造建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
