คำถามติดแท็ก database-design

การพัฒนาสกีมาแนวคิดและ / หรือโมเดลเชิงตรรกะและ / หรือการตั้งค่าทางกายภาพของฐานข้อมูล

4
วิธีที่เหมาะสมในการจัดเก็บค่าที่อาจแตกต่างกันหลายประเภท
ฉันมีตารางคำตอบและตารางคำถาม ตารางคำตอบมีค่า แต่ขึ้นอยู่กับคำถามที่ว่าค่านี้อาจจะเป็นbit, nvarcharหรือnumber(ไกล) คำถามที่มีความคิดของสิ่งที่คำตอบประเภทค่าตั้งใจที่ควรจะเป็น การแยกวิเคราะห์ค่าคำตอบเหล่านี้จะต้องมีความสำคัญเนื่องจากจะต้องเปรียบเทียบอย่างน้อยหนึ่งตัวเลข สำหรับบริบทเพิ่มเติมอีกเล็กน้อยคำถามและคำตอบที่เป็นไปได้ (โดยทั่วไปคือประเภทข้อมูลที่อนุญาตให้ป้อนข้อมูลประเภทกล่องข้อความ) ได้รับการจัดทำโดยผู้ใช้บางรายในการสำรวจเรียงลำดับ คำตอบนั้นจะได้รับจากผู้ใช้ที่ระบุรายอื่น ตัวเลือกสองสามอย่างที่ฉันพิจารณาคือ: A. XML หรือสตริงที่ได้รับการวิเคราะห์คำแตกต่างกันไปขึ้นอยู่กับประเภทที่ต้องการ (ซึ่งถูกติดตามในคำถาม) B. ตารางที่แยกต่างหากสามตารางที่อ้างอิง (หรืออ้างอิงโดย) ตารางตอบรับและเข้าร่วมตามประเภทที่ต้องการ ในกรณีนี้ฉันไม่แน่ใจว่าวิธีที่ดีที่สุดในการตั้งค่าข้อ จำกัด เพื่อให้แน่ใจว่าคำถามแต่ละข้อมีคำตอบเดียวเท่านั้นหรือควรทิ้งไว้ในแอปพลิเคชัน C. สามคอลัมน์แยกกันในตาราง Answer ที่สามารถดึงข้อมูลได้ตามประเภทที่ต้องการ ฉันยินดีที่จะได้รับข้อมูลเกี่ยวกับข้อดีข้อเสียของวิธีการเหล่านี้หรือวิธีการอื่นที่ฉันไม่ได้พิจารณา

3
แนวทางปฏิบัติที่ดีที่สุดสำหรับตารางประวัติ / เวลา
สมมติว่าฉันมีวัตถุมีบางฟิลด์ที่ฉันต้องการติดตามประวัติและบางฟิลด์ที่ฉันไม่ต้องการติดตามประวัติ จากมุมมองของการทำให้เป็นมาตรฐานคือสกีมาดังต่อไปนี้: CREATE TABLE MyObject AS ( MyObjectId INT IDENTITY NOT NULL PRIMARY KEY, MyObjectField1 VARCHAR(100) NOT NULL, MyObjectField2 VARCHAR(100) NOT NULL, MyObjectField3 VARCHAR(100) NOT NULL, MyObjectTrackedField1 VARCHAR(100) NOT NULL, MyObjectTrackedField2 VARCHAR(100) NOT NULL, MyObjectTrackedField3 VARCHAR(100) NOT NULL, ) CREATE TABLE MyObjectHistory AS ( MyObjectHistoryId INT IDENTITY NOT NULL PRIMARY …


1
การเอาชนะข้อ จำกัด ของ SQL Server Express Edition
Microsoft SQL Server 2014 Express edition มีการ จำกัด ขนาดฐานข้อมูลไว้ที่ 10GB ตอนนี้เป็นเพียงอินสแตนซ์เดียวหรือขนาดโดยรวมที่รุ่นจะอนุญาตหรือไม่ หรือหมายความว่าฉันสามารถมีฐานข้อมูลได้มากเท่าที่ใช้รุ่นที่ให้แต่ละฐานข้อมูลน้อยกว่า 10GB

3
ข้อ จำกัด ด้านความซื่อสัตย์ในฐานข้อมูลเชิงสัมพันธ์ - เราควรมองข้ามหรือไม่?
ฉันกำลังสนทนาอย่างถาวรกับผู้พัฒนาของ บริษัท ที่ฉันทำงานอยู่เพราะพวกเขาบอกว่าเป็นการดีกว่าที่จะกำจัดการบังคับใช้ความสัมพันธ์ (ผ่านคำจำกัดความของคีย์ต่างประเทศ) ในฐานข้อมูลเชิงสัมพันธ์เพื่อเพิ่มความเร็วในการสืบค้นที่ใหญ่ขึ้น ประสิทธิภาพ. แพลตฟอร์มภายใต้การพิจารณาคือ MySQL 5.x และไม่มีการตั้งค่า KEY ต่างประเทศแม้ข้อ จำกัด หลักบางประการของตารางที่เกี่ยวข้องจะหายไปซึ่งอย่างน้อยสำหรับฉันก็ไม่สมเหตุสมผล อาจจะถูกและผิด แต่ฉันไม่มีข้อโต้แย้งเพียงพอที่จะพูดคุยเกี่ยวกับสถานการณ์นี้ นี่เป็นวิธีที่ได้รับความนิยมเป็นเวลาสามปีแล้ว ฉันใหม่ใน บริษัท นี้ (เพียงหนึ่งเดือน) แต่เป็นผลิตภัณฑ์ "งาน" มีลังเลที่จะปรับปรุงฐานข้อมูล ไม่เป็นไรสิ่งแรกที่ฉันสังเกตเห็นคือหน้าหนึ่งใช้เวลาโหลด 1 นาที (ใช่ 60 วินาที!) หนึ่งในข้อเรียกร้องที่อยู่เบื้องหลังสถานะของกิจการในปัจจุบันคือฐานข้อมูล“ denormalized” นั้นเร็วกว่าฐานข้อมูลปกติ แต่ฉันไม่เชื่อว่าเป็นเรื่องจริง ข้อความค้นหาที่เกี่ยวข้องส่วนใหญ่รวมการดำเนินการของ JOIN ซึ่งทำให้การทำงานช้ามากและช้ามากด้วยข้อมูลจำนวนมาก (ฐานข้อมูลมีจำนวนแถวนับล้าน) โดยทั่วไปการจัดการการดำเนินงาน "CRUD" ถูกนำไปใช้ในระดับรหัสโปรแกรมแอปพลิเคชัน ตัวอย่างเช่นในการลบข้อมูลบางส่วนจากสมมติว่าTableA: มีความจำเป็นต้องตรวจสอบครั้งแรกได้ทันทีหากมีความสัมพันธ์ระหว่างแถวของบางTableAและTableB, ในกรณีที่ความสัมพันธ์ดังกล่าว“ ตรวจพบ” แล้วรหัสโปรแกรมแอปจะไม่อนุญาตให้ลบแถวที่เกี่ยวข้องแต่ หากรหัสโปรแกรมแอปล้มเหลวด้วยเหตุผลบางอย่างการดำเนินการลบจะ“ สำเร็จ” ไม่ว่าจะมีความสัมพันธ์ใด ๆ …

3
วิธีหลีกเลี่ยงการขึ้นต่อกันแบบวนซ้ำ (การอ้างอิงแบบวงกลม) ระหว่าง 3 ตาราง?
ฉันมี 3 ตาราง: คน เสา ชอบ เมื่อฉันออกแบบโมเดล ER มันมีการพึ่งพาแบบวนรอบ: 1: N คน -------- <โพสต์ 1: N โพสต์ ---------- <ไลค์ 1: N คน -------- <ไลค์ ตรรกะคือ: 1 คนสามารถมีโพสต์ได้มากมาย 1 โพสต์มีไลค์มากมาย 1 คนสามารถชอบโพสต์จำนวนมาก (คนที่สร้างไม่สามารถถูกใจโพสต์ของเขาเอง) ฉันจะลบการออกแบบแบบวงกลมนี้ได้อย่างไร หรือการออกแบบฐานข้อมูลของฉันผิด

5
คำนวณขนาดแถวและขนาดแถวสูงสุดสำหรับตาราง
ปัญหา: มีวิธีคำนวณจำนวนไบต์ที่ใช้โดยการสร้างตารางหรือไม่ฉันรู้ว่าคุณสามารถรับข้อมูลบางอย่างจาก data_schema.tables แต่ข้อมูลนั้นไม่ถูกต้องเพียงพอ สิ่งที่จำเป็นจริง ๆ คือจำนวนไบต์ตามคำจำกัดความของตารางสำหรับinnodb เท่านั้นและการเปรียบเทียบอาจพิจารณาเป็นutf-8-general-ci ตัวอย่างเช่นการทดสอบตารางมีดังนี้ สร้างการทดสอบตาราง ( col1 varchar (25), col2 int, col3 varchar (3), col4 ถ่าน (15), col5 datetime ); ตอนนี้จะต้องทราบขนาดแถวทั้งหมดที่สามารถสะสมในหนึ่งแถวตามประเภทของคอลัมน์ในตาราง พบวิธีการแก้ปัญหาที่คล้ายกันใน MSSQL แต่ต้องการรุ่น MySQL ของมัน สคริปต์เพื่อประมาณขนาดแถวสำหรับตารางใด ๆ ความช่วยเหลือใด ๆ ที่ชื่นชมมาก

2
การจัดเก็บที่อยู่การเรียกเก็บเงินวิธีปฏิบัติที่ดีที่สุดในตารางคำสั่งซื้อ
ใครสามารถช่วยฉันเข้าใจคำตอบของผู้ใช้นี้สำหรับตารางตำแหน่งที่อยู่ของลูกค้า ฉันต้องการวิธีการที่ดีในการจัดเก็บที่อยู่ในตารางคำสั่งซื้อ สิ่งที่ฉันกำลังมองหาคือวิธีการตั้งค่าที่อยู่ของฉันดังนั้นเมื่อฉันแก้ไขที่อยู่ใบสั่งจะไม่ได้รับผลกระทบจากความจริงที่ว่าลูกค้าอัปเดตที่อยู่หรือย้ายที่อยู่ ตามที่สคีมาของฉันนั้นดูคล้ายกับ: Person |EntityID| EntityAddress |EntityID|AddressID| Address |AddressID|AddressType|AddressLine1|AddressLine2| Order |OrderID|BillingAddressID|

3
ทำไมไม่แบ่งพาร์ติชัน?
เมื่อใดที่ไม่ต้องการแบ่งพาร์ติชันฐานข้อมูล (คิดMySQL แบ่ง ) ในกรณีของฉัน ฉันจะเริ่มต้นด้วยสองสามล้านแถวก็ควรเติบโตจากที่นั่น คีย์หลักในฟิลด์อักขระที่ทำหน้าที่เป็นตัวยับยั้งเคียวรีที่พบบ่อยที่สุด (และการค้นหาบ่อยครั้ง - อย่างน้อยสองสามต่อวินาที) คีย์หลักจะถูกแฮชเพื่อใช้เป็นพาร์ติชันคีย์ การอัปเดตจะทำกับทุกแถวที่ถูกดึงในคิวรีที่พบบ่อยที่กล่าวถึงข้างต้น การค้นหาน้อยลง (เทียบกับคอลัมน์วันที่หรืออื่น ๆ ) จะต้องกดพาร์ทิชันทั้งหมด แม้แต่ในจุดสุดท้ายการค้นหาไม่ทำงานคู่ขนานดังนั้นในทุกกรณีนี่คือชัยชนะหรือไม่ ข้อเสียของการแบ่งพาร์ติชั่นคืออะไร ทำไมมันไม่ได้เป็นสิ่งที่ทุกคนใช้เป็นค่าเริ่มต้นอย่างน้อยเมื่อคุณดูที่บันทึกนับล้าน + อัปเดต - ฉันเลือกคำตอบของ zgguy แต่ทราบว่าฉันได้เพิ่มคำตอบของตัวเองพร้อมกับผลการวิจัยของตัวเองรวมถึงลิงค์ไปยังคำตอบที่ดีจริงๆสำหรับคำถามที่คล้ายกันซึ่งเป็นประโยชน์อย่างมากสำหรับฉัน

1
เป็นวิธีที่ถูกต้องเพื่อให้แน่ใจว่ารายการที่ไม่ซ้ำกันในการออกแบบฐานข้อมูลชั่วคราวคืออะไร?
ฉันมีปัญหากับการออกแบบฐานข้อมูลชั่วคราว ฉันจำเป็นต้องรู้วิธีการตรวจสอบให้แน่ใจว่าฉันมีบันทึกการใช้งานเพียงหนึ่งเดียวสำหรับระยะเวลาที่กำหนดสำหรับร้านค้า ฉันได้อ่านคำตอบนี้แล้ว แต่ฉันเกรงว่าฉันไม่สามารถคาดหัวได้ว่าไกทำงานอย่างไร โดยเฉพาะอย่างยิ่งฉันจะทำงานที่กระตุ้นให้มีอยู่ของฉันที่ป้องกันการปรับปรุงเพื่อบันทึกและแทรกบันทึกใหม่แทน ปัญหาที่แท้จริงของฉันคือฉันไม่รู้วิธีป้องกัน Store จากวันที่มีผลมากกว่าหนึ่งวันเมื่อวันที่เสร็จสิ้นเป็นโมฆะ (เช่นป้องกันการบันทึก 2 รายการสำหรับร้านค้า) นี่คือสิ่งที่ฉันมี แต่มันช่วยให้ฉันสามารถแทรกบันทึกใหม่สำหรับร้านค้าที่มีวันที่มีประสิทธิภาพที่แตกต่างกัน นิยามของตาราง: /****** Object: Table [PCR].[Z_STORE_TEAM] Script Date: 05/09/2014 13:05:57 ******/ IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[Z_STORE_TEAM]') AND type in (N'U')) DROP TABLE [Z_STORE_TEAM] GO IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id …

1
การออกแบบฐานข้อมูลสำหรับการจัดการ 1 พันล้านแถวและการนับ
เราได้รับข้อมูล GPS แบบเรียลไทม์ในอัตราประมาณ 5,000 ราคา นาที (จากเซิร์ฟเวอร์ TCP 4 แห่ง) แต่ละเซิร์ฟเวอร์ใช้การเชื่อมต่อเดียวเพื่อแทรกข้อมูลและบัฟเฟอร์ข้อมูลระหว่างแทรก ทุกๆ 15 นาทีหรือมากกว่านั้นบริการจะดึงข้อมูลนี้และประมวลผลไปยังการเดินทาง เมื่อสร้างการเดินทางแล้วข้อมูล GPS ที่แท้จริงมักไม่สำคัญนักหากผู้ใช้ต้องการเห็นเส้นทางบนแผนที่ ปัญหาคือดูเหมือนว่าฐานข้อมูลกำลังดิ้นรนเพื่อให้ทันกับอัตราของข้อมูลที่ถูกแทรก บางครั้งเมื่อโหลดเพิ่มขึ้นเวลาใส่เพิ่มสูงขึ้นอย่างกะทันหัน (> 30 วินาที) ซึ่งจะช่วยให้สามารถบัฟเฟอร์ข้อมูลได้มากขึ้นซึ่งจะส่งผลให้เม็ดมีดมีขนาดใหญ่ขึ้น ฉันหวังว่าจะได้รับความคิดเห็นเกี่ยวกับการออกแบบในปัจจุบันและความคิดบางอย่างที่เราต้องปรับปรุงประสิทธิภาพและคำตอบสำหรับคำถามของเรา - และเคล็ดลับอื่น ๆ ที่ผู้คนอาจมี! การออกแบบในปัจจุบัน ขณะนี้ข้อมูลถูกแยกออกเป็นตารางที่แสดงถึงหนึ่งสัปดาห์และข้อมูลที่เก่ากว่าปีถูกเก็บถาวรลงในฐานข้อมูลรอง สิ่งทั้งหมดถูกรวมเข้าด้วยกันในมุมมองที่แก้ไขได้ซึ่งใช้สำหรับแทรกและอ่าน ออกแบบโต๊ะ รหัส (PK, ตัวระบุที่ไม่ซ้ำ) DeviceId (FK, int) PersonId (FK, int) รหัสยานพาหนะ (FK, int) TokenId (FK, int) UtcTime (PK, datetime2 …

2
การออกแบบคลังข้อมูลสำหรับการรายงานข้อมูลกับเขตเวลาต่างๆ
เรากำลังพยายามปรับการออกแบบคลังข้อมูลให้เหมาะสมซึ่งจะสนับสนุนการรายงานข้อมูลสำหรับเขตเวลาต่างๆ ตัวอย่างเช่นเราอาจมีรายงานมูลค่ากิจกรรมหนึ่งเดือน (หลายล้านแถว) ที่ต้องแสดงกิจกรรมที่จัดกลุ่มตามชั่วโมงของวัน และแน่นอนว่าชั่วโมงของวันนั้นจะต้องเป็นชั่วโมง "ท้องถิ่น" สำหรับเขตเวลาที่กำหนด เรามีการออกแบบที่ทำงานได้ดีเมื่อเราเพิ่งสนับสนุน UTC และเวลาท้องถิ่น การออกแบบมาตรฐานของมิติวันที่และเวลาสำหรับ UTC และเวลาท้องถิ่นรหัสของบนตารางข้อมูลจริง อย่างไรก็ตามวิธีการดังกล่าวดูเหมือนจะไม่ขยายหากเราต้องสนับสนุนการรายงานสำหรับเขตเวลา 100+ ตารางความจริงของเรากว้างขึ้นมาก นอกจากนี้เราจะต้องแก้ปัญหาไวยากรณ์ใน SQL เพื่อระบุวันที่และเวลาที่จะใช้สำหรับการจัดกลุ่มในการเรียกใช้รายงานใด ๆ อาจเป็นคำสั่งกรณีที่มีขนาดใหญ่มาก? ฉันเห็นคำแนะนำเพื่อรับข้อมูลทั้งหมดตามช่วงเวลา UTC ที่คุณครอบคลุมจากนั้นส่งคืนไปยังเลเยอร์การนำเสนอเพื่อแปลงเป็นแบบโลคัลและรวมที่นั่น แต่การทดสอบที่ จำกัด กับ SSRS ชี้ให้เห็นว่าจะช้ามาก ฉันได้อ่านหนังสือบางเล่มเกี่ยวกับเรื่องนี้ด้วยและพวกเขาทั้งหมดพูดว่ามีเพียง UTC และแปลงเป็นไฟล์แสดงหรือมี UTC และหนึ่งในท้องถิ่น จะขอบคุณความคิดและข้อเสนอแนะใด ๆ หมายเหตุ: คำถามนี้คล้ายกับ: การจัดการโซนเวลาใน data mart / warehouseแต่ฉันไม่สามารถแสดงความคิดเห็นกับคำถามนั้นได้ดังนั้นรู้สึกว่าสมควรได้รับคำถามของตัวเอง อัปเดต:ฉันเลือกคำตอบของแอรอนหลังจากเขาทำการอัปเดตที่สำคัญและโพสต์โค้ดตัวอย่างและไดอะแกรม ความคิดเห็นก่อนหน้าของฉันเกี่ยวกับคำตอบของเขาจะไม่สมเหตุสมผลอีกต่อไปเนื่องจากพวกเขาอ้างถึงการแก้ไขคำตอบเดิม ฉันจะพยายามกลับมาและอัปเดตสิ่งนี้อีกครั้งหากรับประกัน

1
วิธีปฏิบัติที่ดีที่สุดสำหรับการจัดเก็บข้อมูลเมตาของระเบียน
แนวปฏิบัติที่ดีที่สุดสำหรับการจัดเก็บข้อมูลเมตาของแต่ละระเบียนในฐานข้อมูลคืออะไร ฉันต้องการจัดเก็บข้อมูลเมตาทั่วไปเช่นเวลาสร้างและเวลาของการอัปเดตครั้งล่าสุดสำหรับตารางจำนวนมากในฐานข้อมูลของฉัน ฉันพบวิธีแก้ไขปัญหาต่าง ๆ : เก็บข้อมูลเมตาโดยตรงในตาราง ข้อดี: ข้อมูล Meta เชื่อมโยงโดยตรงกับบันทึก ไม่จำเป็นต้องใช้ตัวเชื่อมเพื่อดึงข้อมูลเมตา จุดด้อย: จำเป็นต้องใช้คอลัมน์ที่ซ้ำกันจำนวนมาก (เว้นแต่จะใช้การสืบทอด) ข้อมูล Meta และข้อมูลธุรกิจจะไม่แยกออกจากกัน สร้างตารางข้อมูลเมตาทั่วไปด้วยและใช้ซอฟต์คีย์ต่างประเทศเพื่อลิงค์ข้อมูลไปยังตารางและเรกคอร์ดที่ถูกต้อง ข้อดี: ไม่มีการทำซ้ำคอลัมน์ ข้อมูล Meta ถูกแยกออกจากข้อมูลธุรกิจ จุดด้อย: ไม่มีลิงก์โดยตรงระหว่างข้อมูลเมตาและข้อมูล (ไม่สามารถใช้ FK ได้) เข้าร่วมต้องมีเงื่อนไขเพิ่มเติม สร้างตารางข้อมูลเมตาแต่ละตารางสำหรับแต่ละตารางที่ต้องการข้อมูลเมตา ข้อดี: ข้อมูล Meta เชื่อมโยงโดยตรงกับบันทึก ข้อมูล Meta ถูกแยกออกจากข้อมูลธุรกิจ จุดด้อย: ต้องใช้ตารางเสริมจำนวนมาก จำเป็นต้องใช้คอลัมน์ที่ซ้ำกันจำนวนมาก (เว้นแต่จะใช้การสืบทอด) มีตัวเลือกข้อดีหรือข้อเสียมากกว่าตัวเลือกที่ฉันพูดถึงที่นี่หรือไม่? และวิธีปฏิบัติที่ดีที่สุดในการจัดเก็บข้อมูลเมตานี้คืออะไร

3
คอลัมน์ nullable สองคอลัมน์จำเป็นต้องมีค่า
คำถามที่ไม่มีคำอธิบาย: อย่างไรก็ตามมีข้อ จำกัด ของค่า Null 2 ​​ค่าที่ต้องมีค่า 1 เสมอหรือไม่ ตัวอย่างเช่นสองคอลัมน์วันที่ทั้งเป็นโมฆะ แต่มีอย่างน้อย 1 ที่ต้องมีค่า คำอธิบายปัญหา: สมมติว่าฉันมีตารางที่เรียกว่าค่าใช้จ่าย และมี 2 วัน: prevision_expense_expiration_date DATE NULLABLE ค่าใช้จ่าย _payment_date DATE NULLABLE ตรรกะของคอลัมน์ 2 คอลัมน์ดังต่อไปนี้: ฉันซื้อของบางอย่างและฉันรู้ว่าฉันต้องจ่ายเงินสำหรับบางวันเช่นค่าโทรศัพท์ ฉันจะป้อนสิ่งนี้เป็นค่าใช้จ่ายโดยมี costs_payment_date วันนี้เป็นวันที่ควรจะจ่าย แต่ไม่ใช่วันที่จ่ายจริงเช่นวันหมดอายุของใบแจ้งหนี้ ในสถานการณ์อื่น ๆ ฉันขายบัตรของขวัญของผู้ให้บริการบางรายเพื่อให้บริการ ฉันอาจมีค่าใช้จ่ายในการซื้อให้กับผู้ให้บริการของฉันบริการโอนไปยังลูกค้าของฉันเฉพาะในกรณีที่ลูกค้าแลกบัตร ดังนั้นบัตรของขวัญจึงมีวันหมดอายุฉันต้องการทำเช่นนั้นสำหรับ 'ค่าใช้จ่าย' โดยไม่ต้องใส่เป็นค่าใช้จ่ายสำหรับเวลาที่บัตรของขวัญนั้นถูกต้องหากบัตรของขวัญหมดอายุ 'ค่าใช้จ่าย' นั้นไม่ควรเข้าบัญชี ระบบ. ฉันรู้ว่าฉันสามารถมี 2 ตารางเท่า ๆ กันที่เรียกว่า prevision_expense และ …

1
เป็นความคิดที่ดีที่จะใช้ฐานข้อมูลเดียวสำหรับร้านค้ากว่า 50,000 แห่งหรือไม่?
ฉันรู้ว่า Shopify ใช้ฐานข้อมูลเดียวเท่านั้นสำหรับร้านค้าทั้งหมด แต่พวกเขาสามารถจัดการฐานข้อมูลด้วยข้อมูลขนาดใหญ่ได้อย่างไร เป็นความคิดที่ดีที่จะใช้ฐานข้อมูลเดียวสำหรับร้านค้ากว่า 50,000 แห่งหรือไม่?

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.