इकाई फ्रेमवर्क: प्राथमिक कुंजी के बिना तालिका

Question

मेरे पास एक मौजूदा डीबी है जिसके साथ मैं एक नए ऐप का उपयोग करना चाहता हूं EF4.0

कुछ तालिकाओं में प्राथमिक कुंजी परिभाषित नहीं है ताकि जब मैं एक नया डेटा डेटा मॉडल बनाऊं, तो मुझे निम्नलिखित संदेश मिले:

The table/view TABLE_NAME does not have a primary key defined 
and no valid primary key could be inferred. This table/view has 
been excluded. To use the entity, you will need to review your schema, 
add the correct keys, and uncomment it.

यदि मैं उनका उपयोग करना चाहता हूं और डेटा को संशोधित करना चाहता हूं, तो क्या मुझे जरूरी रूप से उन तालिकाओं में एक पीके जोड़ना चाहिए, या क्या कोई वर्कअराउंड है ताकि मुझे नहीं करना पड़े?

Comments

जो सेल्को को उद्धृत करने के लिए: यदि इसके पास प्राथमिक कुंजी नहीं है, तो यह तालिका नहीं है । पृथ्वी पर कोई भी प्राथमिक कुंजी के बिना "नियमित" तालिका क्यों बनाएगा ?? बस उन पीके जोड़ें! आपको उनकी आवश्यकता होगी - बल्कि बाद में जल्द ही ....

— marc_s

यदि इसका एक दृश्य इस हावा एक नज़र इस मामले stackoverflow.com/a/10302066/413032

— Davut Gürbüz

यह पूरी तरह से मान्य है कि प्रत्येक तालिका को प्राथमिक कुंजी की आवश्यकता नहीं है। अक्सर उपयोगी नहीं, लेकिन मान्य। ईएफ को भ्रमित करना एक अच्छा कारण है, ऐसा नहीं है कि इसमें बहुत कुछ है। ;-)।

— सनकैट

कल्पना कीजिए कि मैं अपनी कंपनी पर डीबी संरचना को संशोधित नहीं कर सकता और यह किसी ने बनाया था कि तालिका संरचना को बदल न जाए, यह परिदृश्य संभव है।

— टीटो

यह ठीक वही है जहाँ हम हैं। हमें 3rd पार्टी ओरेकल डेटाबेस के साथ काम करना होगा जिसमें कोई प्राथमिक कुंजी नहीं है।

— डेविड ब्राउनर

Answer 1

त्रुटि का मतलब वही है जो यह कहता है।

यहां तक ​​कि अगर आप इसके आसपास काम कर सकते हैं, तो मुझ पर विश्वास करें, आप नहीं करना चाहते हैं। भ्रमित करने वाले कीड़े की संख्या को पेश किया जा सकता है, यह बहुत ही डरावना और डरावना है, इस तथ्य का उल्लेख नहीं करने के लिए कि आपका प्रदर्शन संभवतः ट्यूबों के नीचे जाएगा।

इस के आसपास काम मत करो। अपना डेटा मॉडल ठीक करें।

संपादित करें: मैंने देखा है कि बहुत से लोग इस प्रश्न को खारिज कर रहे हैं। यह ठीक है, मुझे लगता है, लेकिन यह ध्यान रखें कि ओपी ने एक प्राथमिक कुंजी के बिना एक तालिका को मैप करने के बारे में पूछा , न कि एक दृश्य । जवाब अभी भी वही है। तालिकाओं पर पीके की आवश्यकता के आसपास काम करना प्रबंधनीयता, डेटा अखंडता और प्रदर्शन के दृष्टिकोण से एक बुरा विचार है।

कुछ ने टिप्पणी की है कि उनके पास अंतर्निहित डेटा मॉडल को ठीक करने की क्षमता नहीं है क्योंकि वे तृतीय-पक्ष एप्लिकेशन के लिए मैप कर रहे हैं। यह एक अच्छा विचार नहीं है, क्योंकि मॉडल आपके नीचे से बदल सकता है। यकीनन, उस स्थिति में, आप एक दृश्य में मैप करना चाहते हैं, जो, फिर से, ओपी ने पूछा नहीं है।

Comments

आम सीरियसनेस में सहमत हैं, लेकिन लॉग टेबल जैसी दुर्लभ सीरियसनेस में आपको सिर्फ एएसएपी रिकॉर्ड डालने की जरूरत है। पीके होने पर एक मुद्दा हो सकता है जब अद्वितीयता और इंडेक्सिंग की जांच होती है। इसके अलावा, यदि आपका पीके पहचान है तो उत्पन्न मूल्य को ईएफ में वापस करना एक और मुद्दा है। इसके बजाय GUID का उपयोग कर रहे हैं? पीढ़ी का समय और अनुक्रमण / छँटाई एक और मुद्दा है! ... SO कुछ महत्वपूर्ण OLTP सीनावेयर (जैसे लॉगिंग) में, कोई PK नहीं है और यह कोई सकारात्मक बिंदु नहीं है!

— महमूद मोरविज

@MahmoudMoravej: सबसे पहले, क्लस्टरिंग इंडेक्स और प्राथमिक कुंजी के विचारों को मिलाएं नहीं। वे एक ही चीज नहीं हैं। आपके पास IDENTITY स्तंभों पर क्लस्टर किए गए संकेतों के साथ तालिकाओं पर बहुत उच्च प्रदर्शन आवेषण हो सकते हैं। यदि आप सूचकांक रखरखाव के साथ मुद्दों में भाग लेते हैं, तो आपको तालिका को ठीक से विभाजित करना चाहिए। बिना क्लस्टर किए इंडेक्स वाली टेबल छोड़ने का मतलब यह भी है कि आप डिलीट होने के बाद स्पेस को दोबारा प्राप्त करने के लिए इसे प्रभावी ढंग से डिफ्रैग्मेंट नहीं कर सकते। मुझे उस गरीब व्यक्ति पर दया आती है जो आपकी लॉगिंग टेबल को क्वेरी करने की कोशिश करता है अगर उसके पास कोई इंडेक्स नहीं है।

— डेव मार्कल

"अपने डेटा मॉडल को ठीक करें" एक वास्तविक जवाब नहीं है। कभी-कभी हमें कम-से-आदर्श स्थितियों के साथ रहना पड़ता है, जिन्हें हमने नहीं बनाया और बदल नहीं सकते। और, जैसा @Colin ने कहा, वहाँ एक तरीका है कि ओपी पूछ रहा था कि वास्तव में क्या करना है।

— द सेमुर्फ

EF को संतुष्ट करने के लिए कोड बदलना अपने आप में एक वर्कअराउंड है। सभी तालिकाओं को एक प्राथमिक कुंजी की आवश्यकता नहीं है और न ही उन्हें मजबूर किया जाना चाहिए। जैसे आपने एक विषय लिया है और इसमें 0 या कई कीवर्ड हैं। कीवर्ड तालिका में मूल विषय आईडी और संबंधित कीवर्ड हो सकते हैं। यह कहने के लिए कि मुझे अपने DB becasue EF को फिर से तैयार करने की आवश्यकता है, मुझे लंगड़ा करने के लिए मजबूर करता है।

— मृकफ़ डे

इसे अस्वीकृत कर दिया जाना चाहिए क्योंकि यह प्रश्न का उत्तर नहीं देता है। हमें अक्सर तीसरे पक्ष के डेटाबेस के साथ काम करने की आवश्यकता होती है जिसे बदला नहीं जा सकता है।

— कर्रें

Answer 2

मुझे लगता है कि यह टिलिटो द्वारा हल किया गया है:

इकाई फ्रेमवर्क और SQL सर्वर दृश्य

मैं उसकी प्रविष्टि नीचे उद्धृत करूँगा:

हमारे पास एक ही समस्या थी और यह समाधान है:

इकाई कुंजी को एक प्राथमिक कुंजी के रूप में एक कॉलम का उपयोग करने के लिए बाध्य करने के लिए, ISNULL का उपयोग करें।

इकाई कुंजी को एक प्राथमिक कुंजी के रूप में एक कॉलम का उपयोग नहीं करने के लिए मजबूर करने के लिए, NULLIF का उपयोग करें।

इसे लागू करने का एक आसान तरीका यह है कि आप अपने दृश्य के चुनिंदा कथन को दूसरे चयन में लपेटें।

उदाहरण:

SELECT
  ISNULL(MyPrimaryID,-999) MyPrimaryID,
  NULLIF(AnotherProperty,'') AnotherProperty
  FROM ( ... ) AS temp

17 अप्रैल को 17:00 बजे तक टिलिटो ने जवाब दिया

Comments

+1 यह एक सही जवाब है, एक आदर्श दुनिया में सभी विरासत डेटाबेसों में जाना और संदर्भात्मक अखंडता को संशोधित करना बहुत अच्छा होगा, लेकिन वास्तव में यह हमेशा संभव नहीं है।

— डायलन हेस

मैं इसकी सिफारिश नहीं करूंगा। विशेष रूप से ISNULL भाग। यदि ईएफ दो पीके का एक ही पता लगाता है, तो यह अद्वितीय रिकॉर्ड (रों) को प्रस्तुत नहीं कर सकता है, और इसके बजाय एक साझा वस्तु लौटाता है। ऐसा मेरे साथ पहले भी हो चुका है।

— टोड

@Todd - यदि MyPrimaryID एक नहीं पूर्ण स्तंभ है, तो ऐसा कभी कैसे हो सकता है?

— जोकूल

@JoeCool, सिर्फ इसलिए कि यह NULL नहीं है, इसका मतलब यह नहीं है कि यह अद्वितीय है। मैंने "इस समाधान को काम करता है ...", क्योंकि कोई फर्क नहीं पड़ता कि यह किस संदर्भ में उपयोग किया जाता है, आपको विशिष्टता का आश्वासन दिया जा सकता है। हालांकि अब इसके बारे में सोचना, अगर कोई रिकॉर्ड हटा दिया जाता है जो निम्नलिखित रिकॉर्ड '' पीके '' को प्रभावी रूप से बदल देगा।

— टॉड

-1, क्योंकि यह जवाब नहीं देता कि एंटिटी फ्रेमवर्क / सी # कोड को कैसे कॉन्फ़िगर किया जाए ताकि एक पहचान पत्र की कमी वाले टेबल पर कैसे मैप किया जा सके। कुछ 3rd पार्टी सॉफ्टवेयर (किसी कारण के लिए) इस तरह से लिखा गया है।

— एंड्रयू ग्रे

Answer 3

यदि मैं उनका उपयोग करना चाहता हूं और डेटा को संशोधित करना चाहता हूं, तो क्या मुझे जरूरी रूप से उन तालिकाओं में एक पीके जोड़ना चाहिए, या क्या कोई वर्कअराउंड है ताकि मुझे नहीं करना पड़े?

इस प्रश्न पर पहुंचने वालों के लिए और एंटिटी फ्रेमवर्क कोर का उपयोग कर रहे हैं, अब आपको जरूरी नहीं कि पीके को तालिकाओं को जोड़ने या किसी भी वर्कअराउंड करने की आवश्यकता है। EF Core 2.1 के बाद से हमारे पास एक नई सुविधा क्वेरी प्रकार है

इसके लिए क्वेरी प्रकार का उपयोग किया जाना चाहिए:

• तदर्थ FromSql () प्रश्नों के लिए वापसी प्रकार के रूप में सेवा करना।
• डेटाबेस दृश्य के लिए मानचित्रण।
• उन तालिकाओं को मैप करना, जिनमें प्राथमिक कुंजी परिभाषित नहीं है।
• मॉडल में परिभाषित प्रश्नों का मानचित्रण।

तो अपने DbContext में केवल नीचे DbQuery<T>की DbSet<T>तरह टाइप की निम्न संपत्ति जोड़ें । मान लें कि आपकी तालिका का नाम है MyTable:

public DbQuery<MyTable> MyTables { get; set; }

Comments

सबसे अच्छा जवाब अगर आप ईएफ कोर का उपयोग कर रहे हैं!

— Jay

Answer 4

समग्र चाबियाँ भी एंटिटी फ्रेमवर्क धाराप्रवाह एपीआई के साथ किया जा सकता है

public class MyModelConfiguration : EntityTypeConfiguration<MyModel>
{
     public MyModelConfiguration()
     {
        ToTable("MY_MODEL_TABLE");
        HasKey(x => new { x.SourceId, x.StartDate, x.EndDate, x.GmsDate });
        ...
     }
}

Comments

इस प्रकार के 'मैनुअल मैपिंग' मामले में, मैंने पाया कि आपके द्वारा दिखाए जाने पर कस्टम कुंजी निर्दिष्ट करना प्रभावी है; इसके अतिरिक्त, यदि आपके पास समग्र कुंजी का लाभ नहीं है (जैसा कि इस उत्तर में दिखाया गया है) तो आप उन ओह-विशेष विशेष कुंजी के लिए एक modelBuilder.Entity<T>()चेन-कॉल को टैग कर सकते .HasDatabaseGeneratedOption(DatabaseGeneratedOption.None)हैं जो प्राकृतिक या समग्र नहीं हैं, लेकिन सक्षम होना चाहिए अद्वितीय होने के लिए (आमतौर पर, वैसे भी।)

— एंड्रयू ग्रे २ '

Answer 5

मेरे मामले में मुझे एक इकाई को व्यू में देखना था, जिसमें प्राथमिक कुंजी नहीं थी। इसके अलावा, मुझे यह दृश्य संशोधित करने की अनुमति नहीं थी। सौभाग्य से, इस दृश्य में एक स्तंभ था जो एक अद्वितीय स्ट्रिंग था। मेरा समाधान इस कॉलम को प्राथमिक कुंजी के रूप में चिह्नित करना था:

[Key]
[DatabaseGenerated(DatabaseGeneratedOption.None)]
[StringLength(255)]
public string UserSID { get; set; }

धोखा ईएफ। पूरी तरह से काम किया, किसी का ध्यान नहीं गया ... :)

Comments

नहीं .. UserIDयदि आप कोड प्रथम दृष्टिकोण का उपयोग कर रहे हैं तो यह कॉलम बनाएगा ..!

— दीपक शर्मा

आपने ईएफ को धोखा नहीं दिया है। आपने केवल Itentityफ़ंक्शन बंद करने की आज्ञा दी है । असल में, अगर मैं सही हूं, तो यह अभी भी UserIDआपके लिए PK के रूप में कॉलम बनाने जा रहा है, लेकिन UserIDजब आप डिफ़ॉल्ट रूप से नया रिकॉर्ड बनाएंगे तो यह अपने आप नहीं बढ़ेगा । इसके अलावा, आपको अभी भी अलग-अलग मान रखने की आवश्यकता है UserID।

— 10

@Celdor UserSID एक स्ट्रिंग है, इसे "स्वचालित रूप से बढ़ा हुआ" कभी नहीं मिलेगा। यदि यह पूर्णांक पहचान स्तंभ था, तो डेटाबेस इसे सम्मिलित रूप से बढ़ाएगा, न कि एंटिटी फ्रेमवर्क।

— रेगिगुएटर

Answer 6

EF को डेटाबेस पर एक प्राथमिक कुंजी की आवश्यकता नहीं होती है। यदि ऐसा होता है, तो आप संस्थाओं को विचारों से नहीं बांध सकते।

आप अपनी प्राथमिक कुंजी के रूप में एक अद्वितीय फ़ील्ड निर्दिष्ट करने के लिए SSDL (और CSDL) को संशोधित कर सकते हैं। यदि आपके पास कोई विशिष्ट फ़ील्ड नहीं है, तो मेरा मानना ​​है कि आप hosed हैं। लेकिन आपके पास वास्तव में एक अनूठा क्षेत्र (और एक पीके) होना चाहिए, अन्यथा आप बाद में समस्याओं में भाग लेंगे।

एरिक

Comments

यह ISNULL हैक से बचा जाता है। लेकिन स्थिति के आधार पर, अन्य उत्तरों की आवश्यकता हो सकती है - मुझे लगता है कि उदाहरण के लिए EF में PK के लिए कुछ डेटा प्रकार समर्थित नहीं हैं।

— टोड

Answer 7

बेकार पहचान कुंजी होने पर कई बार व्यर्थ है। मुझे लगता है कि अगर आईडी का उपयोग नहीं किया गया है, तो इसे क्यों जोड़ें? हालाँकि, Entity इसके बारे में क्षमा नहीं कर रही है, इसलिए ID फ़ील्ड जोड़ना सबसे अच्छा होगा। इस मामले में भी इसका उपयोग नहीं किया गया है, यह गुम पहचान कुंजी के बारे में एंटिटी की लगातार त्रुटियों से निपटने से बेहतर है।

Answer 8

इस समाधान काम करता है

यदि आपके पास PK नहीं है तो भी आपको मैन्युअल रूप से मैप करने की आवश्यकता नहीं है। आपको केवल ईएफ को बताने की जरूरत है कि आपका एक कॉलम इंडेक्स है और इंडेक्स कॉलम अशक्त नहीं है।

ऐसा करने के लिए आप निम्नलिखित की तरह isnull फ़ंक्शन के साथ अपने दृश्य में एक पंक्ति संख्या जोड़ सकते हैं

select 
    ISNULL(ROW_NUMBER() OVER (ORDER BY xxx), - 9999) AS id
from a

ISNULL(id, number) यहाँ मुख्य बिंदु है क्योंकि यह EF को बताता है कि यह कॉलम प्राथमिक कुंजी हो सकता है

Comments

मैं ISNULL भाग का सुझाव नहीं दूंगा। यदि ईएफ दो पीके का पता लगाता है तो यह अद्वितीय रिकॉर्ड को प्रस्तुत नहीं कर सकता है, और इसके बजाय एक साझा वस्तु लौटाता है। ऐसा मेरे साथ पहले भी हो चुका है।

— टोड

आपको isnull का उपयोग करना होगा, अन्यथा EF यह निंदनीय नहीं होगा कि यह अशक्त नहीं है।

— आर्क

Answer 9

उपरोक्त उत्तर सही हैं यदि आपके पास वास्तव में पीके नहीं है।

लेकिन अगर वहाँ एक है, लेकिन यह सिर्फ डीबी में एक सूचकांक के साथ निर्दिष्ट नहीं है, और आप डीबी को नहीं बदल सकते हैं (हाँ, मैं दिलबर्ट की दुनिया में काम करता हूं) आप कुंजी बनाने के लिए मैन्युअल रूप से फ़ील्ड (एस) को मैप कर सकते हैं।

Answer 10

यह @Erick T के उत्तर के लिए एक अतिरिक्त है। यदि अद्वितीय मानों के साथ कोई एकल स्तंभ नहीं है, तो निम्नानुसार समग्र कुंजी का उपयोग करने के लिए समाधान है:

[Key]
[Column("LAST_NAME", Order = 1)]
public string LastName { get; set; }

[Key]
[Column("FIRST_NAME", Order = 2)]
public string FirstName { get; set; }

फिर, यह सिर्फ एक समाधान है। वास्तविक समाधान डेटा मॉडल को ठीक करना है।

Answer 11

यह उत्तर देने में देर हो सकती है ... हालांकि ...

यदि तालिका में प्राथमिक कुंजी नहीं है, तो कुछ परिदृश्य हैं जिनका विश्लेषण करने के लिए ईएफ को ठीक से काम करने की आवश्यकता है। नियम है: EF प्राथमिक कुंजी के साथ तालिकाओं / कक्षाओं के साथ काम करेगा। यह है कि यह कैसे ट्रैकिंग करता है ...

कहते हैं, आपकी तालिका 1. रिकॉर्ड अद्वितीय हैं: विशिष्टता एक ही विदेशी कुंजी कॉलम द्वारा बनाई गई है: 2. रिकॉर्ड अद्वितीय हैं: अद्वितीयता कई स्तंभों के संयोजन से बनाई गई हैं। 3. रिकॉर्ड अद्वितीय नहीं हैं (अधिकांश भाग के लिए *)।

परिदृश्य # 1 और # 2 के लिए आप DbContext मॉड्यूल OnModelCreating विधि में निम्न पंक्ति जोड़ सकते हैं: modelBuilder.Entity ()। HasKey (x => new {x.column_a, x.column_b}); // कई स्तंभों के रूप में यह रिकॉर्ड अद्वितीय बनाने के लिए लेता है।

परिदृश्य # 3 के लिए आप तालिका का अध्ययन करने के बाद भी उपरोक्त समाधान (# 1 + # 2) का उपयोग कर सकते हैं (* वैसे भी सभी रिकॉर्ड क्या बनाते हैं)। यदि आपके पास सभी रिकॉर्डों को विशिष्ट बनाने के लिए सभी कॉलम शामिल होने चाहिए, तो आप अपनी तालिका में एक प्राथमिक कुंजी कॉलम जोड़ना चाह सकते हैं। यदि यह तालिका किसी तीसरे पक्ष के विक्रेता से है, तो इस तालिका को अपने स्थानीय डेटाबेस (रातोंरात या जितनी बार आपको ज़रूरत हो) के साथ प्राथमिक कुंजी कॉलम में आपकी क्लोन स्क्रिप्ट के माध्यम से मनमाना जोड़ा गया है।

Answer 12

1. तालिका संरचना बदलें और एक प्राथमिक कॉलम जोड़ें। मॉडल को अपडेट करें
2. XML संपादक में .EDMX फ़ाइल को संशोधित करें और इस विशिष्ट तालिका के लिए टैग के तहत एक नया कॉलम जोड़ने का प्रयास करें (काम नहीं करेगा)
3. बाहर निकलने की मेज पर एक नया प्राथमिक कॉलम बनाने के बजाय, मैं सभी मौजूदा कॉलमों को शामिल करके एक समग्र कुंजी बनाऊंगा ( काम किया )

एंटिटी फ्रेमवर्क: डेटाटेबल को बिना किसी प्राथमिक कुंजी के एंटिटी मॉडल में जोड़ना।

Comments

मैंने EF 4.0 के साथ कम्पोजिट कुंजी दृष्टिकोण की कोशिश की और यह काम नहीं किया।

— राल्फ विलगॉस

इस दृष्टिकोण ने मेरे लिए पूरी तरह से काम किया, एक विरासत प्रणाली "कभी-कभी" के साथ काम करने वाला दर्द हो सकता है ...

— pinmonkeyiii

Answer 13

@CodeNotFound के उत्तर के लिए अपडेट करें ।

ईएफ कोर 3.0 DbQuery<T>में पदावनत किया गया है, इसके बजाय आपको कीलेस इकाई प्रकारों का उपयोग करना चाहिए जो कि कथित तौर पर ऐसा ही करते हैं। ये ModelBuilder HasNoKey()विधि से कॉन्फ़िगर किए गए हैं । अपने DbContext क्लास में, यह करें

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder
        .Entity<YourEntityType>(eb =>
        {
            eb.HasNoKey();
        });

}

हालांकि प्रतिबंध हैं, विशेष रूप से:

• DbContext में परिवर्तन के लिए कभी भी ट्रैक नहीं किया जाता है और इसलिए इसे डेटाबेस में कभी भी डाला, अपडेट या डिलीट नहीं किया जाता है।
• केवल विशेष रूप से नेविगेशन मैपिंग क्षमताओं के एक सबसेट का समर्थन करें:
  • वे कभी भी रिश्ते के प्रमुख अंत के रूप में कार्य नहीं कर सकते हैं।
  • उनके पास स्वामित्व वाली संस्थाओं के लिए नेवीगेशन नहीं हो सकता है
  • वे केवल नियमित संस्थाओं की ओर इशारा करते हुए संदर्भ नेविगेशन गुण शामिल कर सकते हैं।
  • इकाइयों में बिना चाबी इकाई प्रकार के नेविगेशन गुण नहीं हो सकते।

इसका मतलब है कि प्रश्न के लिए

यदि मैं उनका उपयोग करना चाहता हूं और डेटा को संशोधित करना चाहता हूं, तो क्या मुझे जरूरी रूप से उन तालिकाओं में एक पीके जोड़ना चाहिए, या क्या कोई वर्कअराउंड है ताकि मुझे नहीं करना पड़े?

आप इस तरह से डेटा को संशोधित नहीं कर सकते - हालांकि आप पढ़ सकते हैं। हालांकि डेटा को संशोधित करने के लिए एक अन्य तरीके (जैसे ADO.NET, Dapper) का उपयोग करने की कल्पना की जा सकती है - यह उन मामलों में समाधान हो सकता है जहां आपको शायद ही कभी गैर-पढ़ने वाले ऑपरेशन करने की आवश्यकता होती है और फिर भी अपने बहुमत के मामलों के लिए ईएफ कोर के साथ रहना पसंद करेंगे।

इसके अलावा, अगर आपको वास्तव में हीप (बिना चाबी) के तालिकाओं के साथ काम करने की आवश्यकता है - ईएफ पर विचार करें और अपने डेटाबेस से बात करने के लिए दूसरे तरीके का उपयोग करें।

Answer 14

एक व्यावहारिक दृष्टिकोण से, हर मेज - यहां तक ​​कि एक गोदाम तालिका की तरह एक असामान्य तालिका - में एक प्राथमिक कुंजी होनी चाहिए। या, इसे विफल करते हुए, इसमें कम से कम एक अद्वितीय, गैर-अशक्त सूचकांक होना चाहिए।

कुछ प्रकार की अनूठी कुंजी के बिना, डुप्लिकेट रिकॉर्ड्स (और विल) तालिका में दिखाई देंगे, जो ओआरएम परतों के लिए और डेटा की बुनियादी समझ के लिए दोनों के लिए बहुत समस्याग्रस्त है। एक तालिका जिसमें डुप्लिकेट रिकॉर्ड हैं, संभवतः खराब डिज़ाइन का एक लक्षण है।

बहुत कम से कम, तालिका में कम से कम एक पहचान कॉलम होना चाहिए। ऑटो-जनरेटिंग आईडी कॉलम जोड़ने से SQL सर्वर में लगभग 2 मिनट और Oracle में 5 मिनट लगते हैं। उस अतिरिक्त प्रयास के लिए, कई, कई समस्याओं से बचा जाएगा।

Comments

मेरा आवेदन डेटा वेयरहाउस सेटिंग (ओरेकल के साथ) में है और आपने मुझे एक इंडेक्स जोड़ने के लिए 5 मिनट में जाने के लिए आश्वस्त किया। यह वास्तव में केवल 5 मिनट (या थोड़ा और अधिक अगर आपको इसे देखने या ईटीएल को संशोधित करने की आवश्यकता है ) लेता है ।

— ट्रेंट

Answer 15

हमें इस समस्या का भी सामना करना पड़ा, और जब हमारे पास एक स्तंभ था जिसमें नल थे, तो यह महत्वपूर्ण था कि हमारे पास एक निर्भर स्तंभ था जिसमें नल नहीं थे और इन दो स्तंभों का संयोजन अद्वितीय था।

इसलिए प्रताप रेड्डी द्वारा दी गई प्रतिक्रिया को उद्धृत करना, हमारे लिए ठीक रहा।

Answer 16

मैं बहुत खुश हूँ मेरी समस्या हल हो गई है।

EntitySet को अपडेट करने में असमर्थ - क्योंकि इसमें DefiningQuery है और कोई <UpdateFunction> तत्व मौजूद नहीं है

और ऐसा करें: उस रेखा के नीचे देखें और टैग ढूंढें। इसमें एक बड़ा ol 'सेलेक्ट स्टेटमेंट होगा। टैग निकालें और यह सामग्री है ..

अब डीबी टीआई को बदले बिना एक तालिका में सम्मिलित कर सकते हैं जो पीके नहीं है

सभी को धन्यवाद और ग्रसनी धन्यवाद

Answer 17

ईएफ कोर 5.0 में, आप इसे इकाई स्तर पर भी परिभाषित करने में सक्षम होंगे।

[Keyless]
public class Address
{
    public string Street { get; set; }
    public string City { get; set; }
    public int Zip { get; set; }
}

संदर्भ: https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core-5.0/whatsnew#use-ac-attribute-to-indicate-that-an-entity- है-कोई कुंजी

Answer 18

तालिका में केवल एक कॉलम होना चाहिए जो नल की अनुमति नहीं देता है