Vấn đề nào được giải quyết bằng cách chia địa chỉ đường phố thành các cột riêng lẻ?


24

Chúng tôi có một nhóm thiết kế các bảng và quan hệ cho các nhà phát triển phần mềm. Trong tổ chức của chúng tôi, họ khá nghiêm ngặt trong việc thực thi chuẩn hóa 3NF - thành thật mà nói, tôi đồng ý với quy mô của tổ chức của chúng tôi và nhu cầu hoặc khách hàng của chúng tôi thay đổi theo thời gian như thế nào. Chỉ có một lĩnh vực tôi không rõ về lý do đằng sau quyết định thiết kế của họ: địa chỉ.

Mặc dù điều này chủ yếu tập trung vào các địa chỉ ở Hoa Kỳ, tôi nghĩ rằng điều này có thể áp dụng cho bất kỳ quốc gia nào thực hiện việc này. Mỗi phần của một địa chỉ được cột riêng trong bảng địa chỉ. Ví dụ: lấy địa chỉ Mỹ sởn gai ốc này:

Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222

Nó sẽ được chia ra trong cơ sở dữ liệu như thế này:

  • Số đường phố: 485
  • Tỷ lệ đường phố: 1/2
  • Đường định hướng trước: N (Bắc)
  • Tên đường phố: Smith
  • Loại đường: ST (Đường phố)
  • Đường sau hướng: SW (Tây Nam)
  • Thành phố: Chicago
  • Bang: IL (Illinois)
  • Mã bưu điện: 11111
  • Mã Zip4: 2222
  • Quốc gia (giả sử là Hoa Kỳ)
  • Chú ý: Jane Doe
  • Hộp thư bưu điện: NULL
  • Loại nhà ở: APT (Căn hộ)
  • Số nhà ở: 300B

Và sẽ có một vài cột khác liên quan đến các tuyến đường nông thôn và các tuyến hợp đồng. Hơn nữa, ứng dụng cụ thể của chúng tôi có thể sẽ có một vài địa chỉ quốc tế trong đó. Các nhà lập mô hình dữ liệu cho biết họ sẽ thêm các cột cụ thể cho các địa chỉ quốc tế, đó sẽ là các trường dòng 1, dòng 2 bình thường.

Lúc đầu, tôi nghĩ rằng đây là CÁCH THỨC. Nghiên cứu trực tuyến nhiều lần đề cập đến việc sử dụng dòng địa chỉ 1, 2, 3 và có thể 4, sau đó tách ra thành phố, khu vực và mã bưu chính. Chúng tôi có một trường hợp sử dụng cho ứng dụng mới của chúng tôi, nơi độ chi tiết này có lợi. Chúng tôi phải xác thực rằng người dùng không tạo doanh nghiệp trùng lặp và kiểm tra địa chỉ là một trong những xác nhận. Chúng ta có thể làm cho nó hoạt động với dòng địa chỉ 1 và 2, nhưng sẽ khó khăn hơn.

Đối với ứng dụng cụ thể của chúng tôi, chúng tôi cần lưu trữ nhiều loại địa chỉ cho doanh nghiệp và người dân (vật lý, gửi thư, vận chuyển, v.v.). Chúng tôi có thể cần phải tạo các mẫu thư có thể in được, nhưng yêu cầu đó chưa được thảo luận cho đến nay.

Một số điều khác ứng dụng trong tổ chức của chúng tôi cần hỗ trợ:

  • Kiểm toán (với các bảng lịch sử đầy đủ)
  • In nhãn thư
  • Tạo các mẫu in
  • Báo cáo (cho chính phủ quốc gia và khu vực)

Mặc dù ứng dụng của chúng tôi có thể không làm mọi thứ mà mọi ứng dụng khác đang làm, việc chia địa chỉ thành nhiều thành phần là một tiêu chuẩn doanh nghiệp nơi tôi làm việc. Bất kể ứng dụng của chúng tôi có được hưởng lợi từ nó hay không, chúng tôi buộc phải làm điều này.

Câu hỏi StackOverflow liên quan đến bán: Bộ phân tích địa chỉ tốt đã được đóng ở đâu, nhưng minh họa mức độ khó của các địa chỉ phân tích cú pháp.

Để tôi hiểu rõ hơn về quyết định thiết kế của họ và bán cho khách hàng của chúng tôi về ý tưởng ...

Vấn đề nào được giải quyết bằng cách chia địa chỉ đường phố thành các cột riêng lẻ?

Điểm thưởng cho bất cứ ai đã thực hiện một hệ thống như thế này, vì họ gặp phải vấn đề.


1
Và hãy nhớ rằng một số địa chỉ vẫn không phù hợp với mẫu của bạn - Tôi đã thấy một số địa chỉ đường phố thực sự dọc theo dòng chữ "xuống phố từ nhà máy xi măng" từ các nước đang phát triển.
duskwuff 28/03/2016

1
@duskwuff: Tôi đã đưa nó lên cho họ và đó là lý do tại sao họ thêm "trường địa chỉ quốc tế" - line_1, line_2, line_3. Họ thực sự chỉ muốn tách ra các địa chỉ Hoa Kỳ. Và công bằng mà nói,> 90% địa chỉ trong các ứng dụng này là địa chỉ Hoa Kỳ. Nhưng tôi hoàn toàn hiểu bạn đến từ đâu .
Greg Burghardt

Câu trả lời:


10

Các vấn đề có thể được giải quyết bằng cách chia tách bao gồm

Xác nhận Bất kỳ một phần nào của tên có thể được so sánh với danh sách chính. Những người không phù hợp có thể bị từ chối. Mã bưu điện / mã zip là một ví dụ rõ ràng. Chúng được ban hành và duy trì bởi một cơ quan độc lập. Những người hợp lệ duy nhất là những người được ban hành bởi cơ quan đó.

Sắp xếp và lựa chọn Tôi đã thấy các trường hợp giảm phí bưu chính nếu thư được chuyển đến dịch vụ chuyển phát đã được tổ chức ở một mức độ nào đó. Có các cột tương ứng tạo ra giá trị kinh doanh hữu hình.

Phân tích Có thể hữu ích để biết đơn hàng của bạn sẽ đi đâu, theo cách phân cấp theo địa lý. Điều này có thể thúc đẩy các sáng kiến ​​bán hàng, phát triển sản phẩm hoặc thanh toán hoa hồng, v.v.

Sao chép mã Bằng cách có tất cả các ứng dụng trong một tổ chức áp dụng cùng một mô hình dữ liệu (của người tiêu dùng phức tạp nhất), một cơ sở mã duy nhất có thể được chấp nhận trên toàn doanh nghiệp và được duy trì một cách nhất quán. Chia tóc vô tận có thể tránh được, hoặc ít nhất là ủy thác cho các chân vịt. Địa chỉ được tổ chức bởi các bộ phận khác nhau của tổ chức có thể được cập nhật một cách nhất quán. Dịch vụ khách hàng và sự hài lòng có thể được tăng lên. Nỗ lực phát triển có thể tập trung vào các phần độc đáo, có giá trị cao của một hệ thống.

Các vấn đề pháp lý Luật pháp và thuế thay đổi tùy theo thẩm quyền. Bằng cách nắm bắt các giá trị địa chỉ chi tiết một cách riêng biệt, việc tham chiếu chéo dữ liệu giao dịch theo yêu cầu tuân thủ sẽ dễ dàng hơn.

Sao chép Thật đơn giản để giả mạo các địa chỉ được giữ dưới dạng văn bản bằng cách di chuyển một yếu tố sang dòng tiếp theo hoặc sắp xếp lại một số phần. Địa chỉ được phân tích đầy đủ dễ dàng hơn để so sánh. Đây có thể là một vấn đề chất lượng dữ liệu đơn giản hoặc có thể có sự tuân thủ hoặc liên quan đến tín dụng nếu, nhiều công ty vỏ bọc đặt hàng lớn đến cùng một địa chỉ giao hàng hoặc thẻ tín dụng được sử dụng để giao hàng đến nhiều địa điểm phân tán trong một thời gian ngắn.

Các bộ phận định dạng được tổ chức riêng biệt có thể được kết hợp trong bất kỳ thời trang nào phù hợp với nhu cầu hiện tại. Nếu, giả sử, nhãn in mỏng dài trở nên rẻ, bạn có thể định dạng lại để sử dụng chúng.

Tất nhiên không ai trong số này có thể áp dụng cho bất kỳ ứng dụng cụ thể nào. Dữ liệu thuộc loại này dễ phân tích và xác thực tại nguồn hơn, khi được thu thập, hơn bao giờ hết trong phân tích bài. Vì vậy, ngay cả khi YAGNI, có thể tốt hơn là đặt nỗ lực thêm lên phía trước với chi phí thấp và tiềm năng tiết kiệm lớn trong tương lai.

Cuối cùng, tôi sẽ không loại bỏ yếu tố con người. Mô hình dữ liệu được sản xuất bởi các nhà điều hành dữ liệu. Đó là những gì họ làm. Đó là nghề nghiệp của họ. Họ sẽ không bảo bạn bỏ nó vào BLOB chứ?


3
Tôi nghĩ rằng đây là một câu trả lời đánh giá thấp. Hầu hết các câu trả lời giải quyết nhiều vấn đề có thể phát sinh từ việc chia địa chỉ thành các cột, nhưng tôi nghĩ rằng câu trả lời này thực hiện công việc tốt nhất để tóm tắt những vấn đề được giải quyết. Tôi có thể đăng một câu hỏi tương tự hỏi về các vấn đề được giới thiệu. Mọi giải pháp đều có lợi ích và nhược điểm. Câu trả lời của bạn giải quyết các lợi ích tốt nhất.
Greg Burghardt

17

Tôi đã dành 7 năm để phát triển phần mềm cho một công ty xuất bản và một trong những vấn đề khó khăn nhất mà chúng tôi từng giải quyết là phân tích địa chỉ đường phố trong danh sách đăng ký. Rất hữu ích khi phân chia địa chỉ thành các trường riêng biệt, nhưng bạn không bao giờ có thể, thiết kế EVER cho mọi quang sai bệnh lý có thể của các định dạng và thành phần địa chỉ mà bộ não con người có thể nghĩ ra.

Mọi địa phương đều có thể có những điều kỳ quặc, và đó chỉ là ở Mỹ. Ném vào các quốc gia khác và mọi thứ trở nên khó kiểm soát rất nhanh cho bất kỳ cách tiếp cận nào muốn phân tích mọi địa chỉ. Chỉ hai ví dụ:

Ở Tây Ban Nha, số đường phố luôn đứng sau tên đường và dấu phẩy, và nhiều địa chỉ chứa số thứ tự tầng, chẳng hạn như 1 ° hoặc 3ª, cùng với chữ viết tắt của "left" ("Izda" có nghĩa là cửa bên trái bạn đi lên cầu thang), "phải" ("Dcha") hoặc các khả năng khác. Bây giờ nhân số đó với số lượng các quốc gia và khu vực khác nhau với các phong tục lịch sử khác nhau cho các địa chỉ ... (Nhật Bản? Nông thôn Anh? Hàn Quốc? Trung Quốc?)

Ở Portland, OR, có các trục NS và EW phân chia thành phố thành các góc phần tư Tây Bắc, NE, SW và SE (cũng như một góc phần tư N, nhưng tôi lạc đề). Các đường NS được đánh số tăng dần theo hướng Đông và Tây từ trục này và các địa chỉ trên đường EW được xác định bởi số đường NS là "trăm khối" của số (tức là một ngôi nhà trên đường EW nằm giữa đại lộ 11 và 12 sẽ có một số như 1123). Công cụ khá chuẩn cho địa chỉ Hoa Kỳ.

Tất cả vì vậy thường xuyên bạn chạy vào một địa chỉ Portland như 0205 SW Nebraska St . Một số không dẫn đầu? WTF? Có integercột của tôi cho "số" nhà.

Khi lưới được thiết lập, trục NS được xác định bởi sông Willamette. Tất cả mọi thứ về phía đông của dòng sông là NE hoặc SE, và phía tây của sông NW hoặc SW. Khi thành phố phát triển về phía nam, họ gặp phải sự thật bất tiện là dòng sông uốn khúc về phía Đông, do đó, trục phía Nam bạn có khu vực có vấn đề này nằm ở phía "Tây" của sông nhưng phía Đông của trục. Giải pháp là thêm một số 0 đứng đầu, thực tế là một dấu trừ , với các số tăng dần về phía Đông từ đường trục.

Nếu tôi là bạn, tôi sẽ từ bỏ hy vọng thiết kế hệ thống tối thượng. Bạn không thể bao gồm tất cả các khả năng, và những khả năng mới sẽ được tạo ra khi loài người đẩy vào vùng đất chưa phát triển trước đó.

Đối với các địa chỉ tại Hoa Kỳ, hãy xem USPS đã làm gì trong việc tiêu chuẩn hóa địa chỉ và nhớ tạo house_numbercột a varchar. Trong khi bạn đang ở đó tìm ra cách bạn đang đi để phân tích 1634 EN Fort ngõ Ave .

Đối với phần còn lại của thế giới, có lẽ tôi sẽ cố gắng trừu tượng hóa các trường bổ sung để chi trả 80-90% những gì có khả năng xuất hiện và cung cấp một tập hợp các trường không thể giải thích có thể xử lý mọi thứ khác khi cần thiết. Tức là nếu trình phân tích cú pháp của bạn không xử lý một địa chỉ, hãy lưu nó không được chỉnh sửa và gắn cờ như vậy. Nếu bạn quản lý để phân tích một địa chỉ, hãy đảm bảo bạn nhớ thứ tự mà bạn đã tìm thấy các trường khác nhau để bạn có thể lắp lại nó thành một thứ có thể giao được.

Tôi sẽ nói rằng lĩnh vực quan trọng nhất sẽ là mã bưu điện, nhưng thậm chí đó không phải là một lĩnh vực được đưa ra ở nhiều nơi.

Chúc may mắn. Đây có thể là một nỗ lực thú vị và cực kỳ bực bội, nhưng chìa khóa cho sự tỉnh táo là biết khi nào nên bỏ thử và chỉ lưu trữ đầu vào không được chỉnh sửa, hoặc phân tích một phần với đầu vào ban đầu làm bản sao lưu.


Theo dõi thú vị về các số 0 đứng đầu về số đường phố: Phần tử INPUT số HTML sẽ đăng các số 0 hàng đầu trở lại máy chủ : <input type="number">. Tôi sợ rằng nó sẽ không (ít nhất là trong Firefox dù thế nào đi nữa).
Greg Burghardt

Vậy tại sao nó lại hữu ích để phân chia? Điều gì về việc chỉ cung cấp 3 "dòng" cho địa chỉ?
usr

Và còn có mẫu SW SE Chestnut Ave SW , phổ biến từ IN đến WI.
Ross Presser

@usr Không phải địa chỉ nào cũng phù hợp với ba dòng - chỉ cần sử dụng một varcharvà một trường văn bản nhiều dòng tự do!
dùng253751

Tôi giới hạn bản thân trong hai ví dụ nhưng còn nhiều điều nữa. Nhà 22 Essex, Quảng trường Portman, London NW1 . "22" là một số căn hộ.
Jim Garrison

8

Giống như tất cả các câu hỏi về thiết kế, có một "nó phụ thuộc" đủ điều kiện. Nó phụ thuộc vào câu chuyện dữ liệu của bạn - cách thu thập dữ liệu, cách sử dụng, cách cập nhật, v.v. Tất cả các nhận xét của tôi nên được lấy làm điểm thảo luận, không phải là câu trả lời.

Có vẻ như * bạn có thể hưởng lợi nhiều hơn từ việc sử dụng dịch vụ xác thực địa chỉ hơn là cố gắng xây dựng một dịch vụ cho chính mình. Trong khi chúng rất tốn kém, nhiều dịch vụ như vậy đi kèm với giảm giá gửi thư đáng kể.

Tất nhiên, có một sự thỏa hiệp ở đây, đối với những câu chuyện dữ liệu nhất định. Bạn có thể duy trì các phần địa chỉ được phân tích cú pháp và tạo một cột được tính toán (có thể là các cột) cho địa chỉ kết hợp. Đây là một câu trả lời thực hiện, với tất cả các cảnh báo bình thường ngụ ý.

Tôi đã thực hiện thiết kế địa chỉ phân tích cú pháp. Chúng tôi hoàn toàn cần điều này cho chất lượng dữ liệu VÀ nhu cầu xử lý dữ liệu. Nhưng đó là một doanh nghiệp có địa chỉ vật lý, địa chỉ bưu chính, địa chỉ ảo, v.v.

Vấn đề khác có thể xảy ra là các dịch vụ bưu chính khác nhau yêu cầu cùng một thông tin được trình bày theo các định dạng / đơn đặt hàng / vv khác nhau. Vì vậy, có các phần được mô hình hóa hỗ trợ trình bày cùng một thông tin trong nhiều định dạng và bố cục.

Cuối cùng, bạn không cần phải có hoạt động kinh doanh quốc tế để phải hỗ trợ dữ liệu quốc tế. Ngay cả các doanh nghiệp có trụ sở tại Hoa Kỳ cũng cần hỗ trợ các địa chỉ quốc tế. Đó là một sai lầm dữ liệu lớn để cho rằng bạn sẽ không bao giờ có điều đó. Khách hàng di chuyển, nhà cung cấp thay đổi HQ, thông tin liên hệ của nhà cung cấp có thể là quốc tế ngay cả khi họ có HQ của Mỹ. Ngay cả khi các hệ thống hiện tại của bạn mắc lỗi đó, bạn cũng không muốn tiếp tục điều này.

Tôi đánh giá cao các bài viết và blog của Graham Rhind. Anh ấy là chuyên gia trong lĩnh vực dữ liệu về các loại địa chỉ và sự đánh đổi liên quan đến chúng.


* Tất cả những gì tôi đã nói ở đây là một khái quát chung. Có rất nhiều câu hỏi tôi phải giúp để đi đến một giải pháp thiết kế mà có thể mất vài giờ trò chuyện. Có khả năng một số hình ảnh và một số hồ sơ dữ liệu, quá. Và sau đó rất nhiều câu chuyện dữ liệu thực sự kỳ quặc về địa chỉ.


"Bạn không cần phải có hoạt động kinh doanh quốc tế để phải hỗ trợ dữ liệu quốc tế" - rất đúng. Và trên hết, chúng tôi nằm gần biên giới của một quốc gia khác. Nhóm mô hình đã đưa ra một giải pháp cho các địa chỉ quốc tế, đó là cung cấp các trường dòng 1, dòng 2 và dòng 3 trong cơ sở dữ liệu.
Greg Burghardt

Mặc dù bạn đã nói rằng "đây là một tổng quát hóa", giải pháp một mặt phù hợp cho tất cả các địa chỉ chúng tôi có toàn doanh nghiệp khiến câu trả lời của bạn trở nên dễ áp ​​dụng hơn.
Greg Burghardt

5

Hoàn toàn bỏ qua thách thức to lớn về việc phân tích chính xác những lời nói vô nghĩa mà mọi người cung cấp, lợi ích của việc phân tích cú pháp là nó mang lại cho bạn các kích thước để phân nhóm và sắp xếp. Mã bưu điện, ví dụ. Tuy nhiên, không có khoản tiền nào từ việc phân tích một thứ nguyên cụ thể cho đến khi bạn cần nhóm hoặc sắp xếp theo thứ nguyên đó.

Có gì một địa chỉ, dù sao? Bạn có thể tạo ra một trường hợp tốt đó là một định danh vị trí, nhưng bạn có thể tạo ra một trường hợp tốt không kém đó là hướng dẫn giao hàng - "Xuống phố từ nhà máy xi măng". Ở Úc, mọi người nghĩ mã bưu điện là mã định danh vị trí, nhưng họ không, họ là mã định tuyến - hướng dẫn giao hàng. 4702 là Rockhampton Mail Center, một nút phân phối chính phục vụ một khu vực trải dài từ biển đến Emerald, một thị trấn khai thác cách đất liền 300km.

Nếu bạn muốn xác định vị trí thì Bing và Google có thể mã hóa địa lý trực tiếp từ chuỗi chưa được chỉnh sửa thành tọa độ GPS, có thể được lưu trữ trong một bảng nhỏ, đơn giản cùng với chuỗi không được chỉnh sửa. Họ sử dụng phương pháp chung duy nhất với bất kỳ cơ hội nào có kết quả tốt nhất: xếp hạng phù hợp một phần có trọng số với cơ sở dữ liệu khổng lồ về kết quả được xác thực.

Nếu bạn muốn hướng dẫn giao hàng, bạn vẫn nên giữ chuỗi không được chỉnh sửa bởi vì nó có thể chứa bất cứ thứ gì .

Lưu ý rằng trong cả hai trường hợp, tôi đã khuyến nghị giữ chuỗi không được chỉnh sửa. Đó là bởi vì

  • nó hữu ích theo đúng nghĩa của nó
  • một ngày nào đó bạn sẽ tìm ra cách phân tích nó
  • Một vài ngày sau đó, bạn sẽ tìm ra cách phân tích chính xác
  • điều này không bao giờ kết thúc

Có thể cho rằng một địa chỉ luôn là hướng dẫn giao hàng, chứa ít nhất một mã định danh vị trí. Một bức thư gửi đến "123 Main st, Emerald 4702" mã hóa ba địa điểm: RMC ở phía bắc Rockhampton, Emerald và một địa chỉ đường phố. Bưu điện Rockhampton đơn giản sẽ gửi nó đến RMC. RMC sẽ gửi nó đến bưu điện Emerald và bưu điện Emerald hy vọng sẽ biết nơi tìm 123 đường chính.


"Địa chỉ là gì, dù sao? ... bạn có thể tạo ra một trường hợp tốt như nhau đó là hướng dẫn giao hàng" - Điểm rất tốt. Tôi nghĩ rằng khía cạnh "vị trí" của một địa chỉ và khía cạnh "hướng dẫn phân phối" phải là các trường riêng biệt trong cơ sở dữ liệu trong trường hợp này.
Greg Burghardt

3

Tôi đã thực hiện một hệ thống như thế này trước đây, mặc dù ở Hà Lan. Vấn đề là, loại thông tin này có thể thay đổi theo nhiều cách hơn bạn nghĩ. Đường phố được đổi tên, các thành phố được sáp nhập và như vậy. Thật tuyệt khi có thể cập nhật loại thông tin đó mà không cần phân tích địa chỉ dưới dạng một chuỗi.


3

Tách mã bưu điện / mã zip, tên tòa nhà, tên đường có thể có ý nghĩa. Nhưng sau đó khi bạn bắt đầu thêm thị trấn, thì, khu vực, đó là vấn đề, so với chỉ dòng 1, dòng 2, v.v. Vấn đề là ngay cả tôi và vợ tôi cũng không thể đồng ý về tên của thị trấn chúng tôi sống! Có phải tên làng làng là tên được đặt trong lĩnh vực thị trấn, hay nó đi theo dòng bên dưới tên đường, với thành phố địa phương được đặt trong các lĩnh vực thị trấn? (Một số người bị xúc phạm nếu bạn gọi nơi họ sống ở một ngôi làng thay vì thị trấn, những người khác sống ở cùng địa điểm sẽ bị xúc phạm nếu bạn gọi đó là thị trấn thay vì làng!)

Do đó, cố gắng làm bất cứ điều gì lạ mắt không tốt hơn hệ thống xác minh địa chỉ bạn sử dụng. Nhưng nó thậm chí còn tồi tệ hơn. Ở Anh TẤT CẢ các địa chỉ nên có mã bưu điện, nhưng mã bưu điện không được phân bổ cho đến khi nào đó sau khi một ngôi nhà được xây dựng Vì vậy, một hệ thống phải cho phép mọi quy tắc về địa chỉ bị phá vỡ!


2
Amazon.uk có hệ thống tốt nhất tôi từng thấy, khi tôi nhập địa chỉ, họ cung cấp cho tôi TÙY CHỌN sử dụng địa chỉ "được phê duyệt" phù hợp nhất. Tuy nhiên, địa chỉ được phê duyệt là dành cho một công ty khác trong tòa nhà, hoặc không bao gồm "sàn", v.v., vì bưu điện chỉ vuốt ve là hộp thư, không phải là nơi để lấy thứ gì đó để ký.
Ian Ringrose

2

Ngoài các vấn đề đã được đề cập trong các câu trả lời khác, trong một số ngôn ngữ - cụ thể là tiếng Đức - tên đường có xu hướng phức tạp. Ví dụ, thông thường ở nhiều thị trấn / thành phố của Đức có "Bahnhofstr", con đường đi đến ga xe lửa ("Bahnhof" có nghĩa là ga xe lửa / xe lửa, "Strasse" có nghĩa là đường phố). Chắc chắn bạn có thể tách hai thành phần này ra, nhưng bây giờ nếu bạn muốn đặt chúng lại với nhau (theo chương trình), bạn sẽ nhận được câu hỏi về sự từ chối.

Hoặc, trong ngôn ngữ "lãng mạn" hoặc tiếng Latinh, bạn thường có tên đường phố có dạng "Rue de la Pais" hoặc "Boulevard des Champs-Élysées". Bây giờ bạn có giới từ ("de") và một bài viết xác định ("le" hoặc "la") trong hỗn hợp - và chúng có thể được kết hợp. Họ đại diện cho một phần của loại đường hoặc tên đường phố? (Bạn có thể cần lưu trữ chúng ở một nơi nào đó, nếu không bạn sẽ lại bị suy giảm.)


Tôi đã từng mô hình một cái gì đó như thế này. Nhưng đó là một ứng dụng rất nhỏ, dành cho văn phòng bảo trì tài sản dân cư của một trường đại học cỡ trung bình (ở Mỹ). Tôi đã tạo ra các địa chỉ rất chi tiết vì những lý do sau:

  • Có những con đường trong khu vực có cùng tên nhưng một "loại" đường phố khác (ví dụ "Đại lộ rừng" so với "Tòa án rừng").
  • Người dùng muốn có thể tối ưu hóa công việc bảo trì, ví dụ: nếu có hai hoặc nhiều yêu cầu dịch vụ trên cùng một khối có thể được xử lý cùng một lúc.
  • Người dùng muốn có thể tương quan các vấn đề giữa các đơn vị (căn hộ) khác nhau trong cùng một tòa nhà - ví dụ: nếu nhiều hơn một căn hộ báo cáo nhiệt độ lạnh hoặc nước nóng không đủ.

... Và những lý do khác mà tôi không còn nhớ nữa. (Đây là vào cuối những năm 1980.)

Và một lần nữa, điều này chỉ có ý nghĩa bởi vì có một số lượng địa chỉ khá nhỏ (và quy tắc định dạng địa chỉ) để xử lý. Tôi không tin rằng phương pháp này sẽ mở rộng quy mô, ngay cả khi giới hạn ở các địa chỉ của Hoa Kỳ, vì những lý do đã được đưa ra trong các câu trả lời khác.


1
Ví dụ về những năm 1980 của bạn là một minh họa tuyệt vời cho quan điểm của tôi về việc phân tích bất kỳ kích thước nào bạn cần thao tác và "... lưu trữ chúng hoặc bạn đang bị suy giảm" là một ví dụ hay về lý do tại sao việc giữ văn bản nguồn là rất quan trọng. Nó chắc chắn chứa tất cả các loại phi chức năng mà vẫn phải được bảo tồn. Và nói về những điều không liên quan nhưng thú vị, đại lộ có nghĩa là "lối đi dạo được xây dựng trên đỉnh thành lũy phòng thủ bị phá hủy".
Peter Wone
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.